<div dir="ltr"><div>Following up in case anyone with this same issue discovers this thread via search:</div><div><br></div><div>My problems went away once I added these two new directives to nginx.conf:</div><div><font face="monospace">fastcgi_buffer_size 1024k;<br> fastcgi_buffers 4 2048k;</font><br></div><div><br></div><div>I am not recommending this config for any production use or even any new development setups. For myself, I'm happy to have this crutch so I can eke out a little more life from my existing WSL 1 setup prior to the imminent release of WSL 2.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 12, 2020 at 8:13 AM Bruce Klein <<a href="mailto:brucek@gmail.com">brucek@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Maxim! I don't know if I'll be able to fix it with that but I'll sure learn a lot trying. I appreciate all the pointers on where to look.<div><br></div><div>Best,</div><div>Bruce</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 11, 2020 at 7:54 PM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Mon, May 11, 2020 at 09:38:12AM -1000, Bruce Klein wrote:<br>
<br>
> Hi Maxim,<br>
> <br>
> Thank you the reply, which I appreciate very much. I fully agree in spirit.<br>
> <br>
> In practice, the issue of previous versions not working on WSL is a<br>
> long-standing bug vs WSL that people far more expert than me on unix<br>
> internals, WSL, nginx, and fpm have not yet solved for two years plus,<br>
> other than everyone being told to disable fastcgi_buffering. (If you're<br>
> interested, there's plenty of history in various WSL bug reports to read<br>
> through.)<br>
> <br>
> No doubt the root cause here is a flaw in WSL. That's not on the nginx team<br>
> to fix.<br>
> <br>
> That said, as a practical matter, the once easily available workaround is<br>
> now gone. I'd like to understand what changed in 1.18 and if there is an<br>
> easy adaptation to it, as that seems the path of least resistance.<br>
<br>
To find out how to adapt a workaround - first you'll have to find <br>
out why the workaround used to work. That is, what is the bug in <br>
WSL we are trying to work around.<br>
<br>
Also note that it might not be a good idea to use things which <br>
depend on unexplained workarounds for flaws not fixed for years. <br>
As long as there is no explanation why the workaround work, this <br>
usually means that it can stop working unexpectedly and/or won't <br>
work in some edge cases.<br>
<br>
> For what it's worth, the issue generates no logging in either the nginx<br>
> error logs, access logs, or php7.1-fpm logs. It's impact is visible only on<br>
> the web client side, where the user sees it as a partially received page<br>
> and the net::ERR_INCOMPLETE_CHUNKED_ENCODING is available from the browser<br>
> developer tools once the browser has timed out on waiting for the rest of<br>
> the page.<br>
<br>
So, the problem is that transfer stalls at some point, correct? <br>
This looks like an issue with sockets handling, and some things to <br>
try include:<br>
<br>
1. Check the debug log to find out where things stall from nginx <br>
point of view.<br>
<br>
2. Try different event methods, such as "select" and "poll" <br>
(<a href="http://nginx.org/r/use" rel="noreferrer" target="_blank">http://nginx.org/r/use</a>). Note that this might require you to <br>
compile nginx yourself.<br>
<br>
3. Play with socket-related options, such as tcp_nodelay <br>
(<a href="http://nginx.org/r/tcp_nodelay" rel="noreferrer" target="_blank">http://nginx.org/r/tcp_nodelay</a>) and tcp_nopush <br>
(<a href="http://nginx.org/r/tcp_nopush" rel="noreferrer" target="_blank">http://nginx.org/r/tcp_nopush</a>). Unlikely to help though.<br>
<br>
4. Play with TCP buffers ("listen ... sndbuf=...", assuming it <br>
stalls somewhere while sending to the client) to see if it helps. <br>
Likely a buffer larger than the response size should help.<br>
<br>
5. Play with "fastcgi_max_temp_file_size 0;" and/or "sendfile <br>
on/off".<br>
<br>
As long as playing with buffering used to help somehow, this <br>
suggests that there is a problem with event reporting in the epoll <br>
emulation layer. I don't think that this is something that can be <br>
fixed on nginx side, and any workarounds, including <br>
"fastcgi_buffering off", are likely to fail in some edge cases. <br>
The working solution might be to use other event methods though, <br>
such as "select" or "poll", see above. Or to make sure that <br>
socket buffers are large enough to avoid blocking.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</blockquote></div>
</blockquote></div></div>