Nginx gzip filter compatibility issue about nginx-link-function HOT 4 OPEN

I want to post this to be helpful to anyone finding this thread in case they attempt to test with an text/html content type with UTF-8 charset, because there is a second problem with Nginx's API. If you don't specify the content type length as 9 below, gzip will still fail, because internally nginx is making a hash and then there is no matching hash for this even though text/html works.
The nginx gzip_types directive also does not allow fixing this as far as I can determine. They must have some other code fixing this in other modules since I don't have this problem on my live sites. New modules must have to handle it themselves.

ngx_link_func_write_resp_l(
    ctx,
    200,
    "200 OK",
    strlen("200 OK"),
    "text/html; charset=utf-8",
    9, // we force 9 because nginx doesn't understand how to ignore this part: ; charset=utf-8
    buffer,
    strlen(buffer)
);

from nginx-link-function.

I provided pull request: #19

from nginx-link-function.

hi @brucekirkpatrick

Thanks for your finding, but I am not so sure yet whether is a typo bug from NGINX? As I couldn't find any documentation that this headers_out.content_type_len been classified as one of the headers_out family. Maybe I was wrong, as Nginx been developed/researched by various product.

ngx_link_func_write_resp_l(
    ctx,
    200,
    "200 OK",
    strlen("200 OK"),
    "text/html; charset=utf-8",
    sizeof("text/html") - 1, // I will suggested you to use this kind of method to count the len for "Hardcoded string" as this is strongly adivised by open source community
    buffer,
    strlen(buffer)
);

Workaround solution(haven't tested)

1. You could install the src/http/ngx_http.h into your header path? And you could make that content_type_len updated whenever you need it.

Small note advise, This nginx-link-function is design only for light operation as NGINX is Multi-process single thread IO. And we should not have any heavy process like

1. Connection on Connection Model

• Unless you choose for multithread nginx plugin

2. Heavy encrypt and decrypt logic

• Unless you choose for multithread nginx plugin

from nginx-link-function.

Yes, I initially had a problem with performance and errors, but then I made use of aio threads, and made sure my ngx_link_func_call was not able to run more then 1 concurrent request per thread. I used the thread id modulus the max threads to lock on a element in an array of mutex to achieve this. After this, I had 60 times better performance without errors, about half the speed of the fastest nginx will run on that machine. It seems like your project is still the best way. The reason I lock like this is to avoid any additional locks in the application. Each thread has its own memory space to do write operations to keep it as lock-free as possible.

from nginx-link-function.