POSITION_AUX=true broken in nginx 1.9.11+

[JoyceBabu]

Setting POSITION_AUX=true is not working in nginx 1.9.11+. The module ngx_pagespeed is appearing in both HTTP_FILTER_MODULES and HTTP_AUX_FILTER_MODULES.

ngx_pagespeed is appearing by default in HTTP_FILTER_MODULES. When POSITION_AUX=true, the default entry needs to be removed before it is added to HTTP_AUX_FILTER_MODULES.

[vphantom]

I can confirm this with Nginx 1.19.6 as well: adding POSITION_AUX=true to the build environment causes the resulting binary to go into an endless loop when attempting to start. Errors such as:

nginx: master process /usr/share/nginx/sbin/nginx -g daemon off;(net_instaweb::NgxBaseFetch::Initialize(ngx_cycle_s*)+0x63) [0x55fc7158c557]
nginx: master process /usr/share/nginx/sbin/nginx -g daemon off;(ngx_spawn_process+0x4fe) [0x55fc7150df53]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f3c17cfe2e1]
2021/01/14 11:29:26 [alert] 7#0: [ngx_pagespeed 1.13.35.2-0] [0114/112926:FATAL:ngx_base_fetch.cc(74)] Check failed: event_connection == NULL. event connection already set

…which might explain why #612 is still open despite #906 and #1155.

[oschaaf]

I remember that the POSITION_AUX feature didn't seem to get any traction or testing feedback, or at least the large majority users didn't seem to need it. The plan was to get some feedback on the feature and then flip the switch after building some confidence through that, as the change itself is simple but its implications may not be. See this (6 year old :-) ) [PR review discussion] (#906 (comment)).

[vphantom]

My main use for it would've been to restore mod_headers_more's ability to suppress Nginx's native Server: header. I guess I'm one of very few people who care to go that far and use mod_pagespeed. 😉

[vphantom]

I just dug a little deeper and actually ngx_pagespeed is removing all our custom headers from our responses, both those set with add_header and more_set_headers. This means when PageSpeed is enabled we lose STS, Referrer-Policy, X-XSS-Protection, Allow and even the Set-Cookie emitted by ngx_http_userid. We also lose ETag and Cache-Control (which were overwritten anyway) with ModifyCacheHeaders off. I can't believe we hadn't noticed that before today… 😕

Does nobody else in production need to set any header in Nginx?

[oschaaf]

Does nobody else in production need to set any header in Nginx?

That does seem unlikely to me. Does this happen only with .pagespeed. rewritten urls?

[vphantom]

I tested it with plain image URLs when pagespeed is on. My work-around for now (which turned out to work quite well) is to have Nginx proxy into itself to a private port on the paths I want PageSpeed involved, so I can massage the headers before they go out. The inside server enables PageSpeed and the outside one doesn't.

[oschaaf]

That's one way to solve the problem :-) Now if you could configure thenreverse proxy to cache .pagespeed. resources, you might actually get something else out of it too, and minimize the incurred overhead. (note caching the html is tempting, but harder to set up correctly, but just the .pagespeed. resources should be hassle-free).