Hello!

On Mon, May 11, 2020 at 09:38:12AM -1000, Bruce Klein wrote:

> Hi Maxim,
>
> Thank you the reply, which I appreciate very much. I fully agree in spirit.
>
> In practice, the issue of previous versions not working on WSL is a
> long-standing bug vs WSL that people far more expert than me on unix
> internals, WSL, nginx, and fpm have not yet solved for two years plus,
> other than everyone being told to disable fastcgi_buffering. (If you're
> interested, there's plenty of history in various WSL bug reports to read
> through.)
>
> No doubt the root cause here is a flaw in WSL. That's not on the nginx team
> to fix.
>
> That said, as a practical matter, the once easily available workaround is
> now gone. I'd like to understand what changed in 1.18 and if there is an
> easy adaptation to it, as that seems the path of least resistance.

To find out how to adapt a workaround - first you'll have to find
out why the workaround used to work. That is, what is the bug in
WSL we are trying to work around.

Also note that it might not be a good idea to use things which
depend on unexplained workarounds for flaws not fixed for years.
As long as there is no explanation why the workaround work, this
usually means that it can stop working unexpectedly and/or won't
work in some edge cases.

> For what it's worth, the issue generates no logging in either the nginx
> error logs, access logs, or php7.1-fpm logs. It's impact is visible only on
> the web client side, where the user sees it as a partially received page
> and the net::ERR_INCOMPLETE_CHUNKED_ENCODING is available from the browser
> developer tools once the browser has timed out on waiting for the rest of
> the page.

So, the problem is that transfer stalls at some point, correct?
This looks like an issue with sockets handling, and some things to
try include:

1. Check the debug log to find out where things stall from nginx
point of view.

2. Try different event methods, such as "select" and "poll"
(http://nginx.org/r/use). Note that this might require you to
compile nginx yourself.

3. Play with socket-related options, such as tcp_nodelay
(http://nginx.org/r/tcp_nodelay) and tcp_nopush
(http://nginx.org/r/tcp_nopush). Unlikely to help though.

4. Play with TCP buffers ("listen ... sndbuf=...", assuming it
stalls somewhere while sending to the client) to see if it helps.
Likely a buffer larger than the response size should help.

5. Play with "fastcgi_max_temp_file_size 0;" and/or "sendfile
on/off".

As long as playing with buffering used to help somehow, this
suggests that there is a problem with event reporting in the epoll
emulation layer. I don't think that this is something that can be
fixed on nginx side, and any workarounds, including
"fastcgi_buffering off", are likely to fail in some edge cases.
The working solution might be to use other event methods though,
such as "select" or "poll", see above. Or to make sure that
socket buffers are large enough to avoid blocking.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx