nginx update to 1.18.0 broke my wsl ubuntu 16.04 set up

[Bruce Klein]

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.

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.

Thanks again,
Bruce


On Mon, May 11, 2020 at 9:21 AM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Mon, May 11, 2020 at 08:39:22AM -1000, Bruce Klein wrote:
>
> > Does anyone have nginx 1.18.0 running successfully on WSL?
> >
> > Previous versions have worked fine for me the past couple years as long
> as
> > the standard WSL fix "fastcgi_buffering off" was applied.
> >
> > I just picked up the 1.18.0 update and now I'm back to the old
> > net::ERR_INCOMPLETE_CHUNKED_ENCODING errors you used to see with large
> > pages when fastcgi_buffering was on.
> >
> > Is it possible that as of the 1.18.0 update a different directive is
> > required to turn fastcgi_buffering off? Or that nginx is now ignoring
> this
> > directive?
> >
> > Anyone have any suggestions for me to try? Thanks for any tips!
>
> Things are expected to work regardless of "fastcgi_buffering"
> being on or off.  And the error suggests that there is something wrong
> with the setup.  Instead of trying to work around the problem with
> "fastcgi_buffering", it might be a good idea to actually dig into
> what goes wrong and why the error appears.  In particular, looking
> into error log might be a good idea.
>
> Once the underlying problem is understood, you'll be able to fix
> it properly, without involving magic like "the standard WSL fix".
> And the proper fix is expected to work with any nginx version.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20200511/64ee95e6/attachment.htm>