nginx -V nginx version: nginx/1.0.14 TLS SNI support enabled configure arguments: --conf-path=/usr/local/etc/nginx/nginx.conf --error-log-path=/var/log/staff/nginx/error.log --pid-path=/var/lib/nginx/nginx.pid --lock-path=/var/lib/nginx/nginx.lock --http-log-path=/var/log/staff/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --with-debug --with-http_stub_status_module --with-http_flv_module --with-http_ssl_module --with-http_dav_module --add-module=nginx-push-stream-module --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi
"chunkin off" is used for the HttpChunkinModule which adds support for chunked requests to ngionx - we don't use this module. I have tested keepalive_timeout 0 in the nginx config and it seems now the issues are fixed with nginx, lighttpd and apache 2 over pound. I have not checked it with ngrep due to the fact that I have to reconfigure everything again locally to HTTP instead of HTTPS but I guess now that the response messages now really will be delivered 1:1 to the browser client. Even the Opera browser works again. With keepalive_timeout set on default value, it was just a pain on the comet requests. This has been testen on our development setup. I will rollout the new config to our production servers and test again. After that, I will tell you the results. Thank you so far :) On Tue, May 15, 2012 at 7:39 PM, Roberto Geraldo Pimenta Ribeiro Junior < [email protected]> wrote: > Try this for nginx….**** > > *De:* Roberto Geraldo Pimenta Ribeiro Junior > *Enviada em:* terça-feira, 15 de maio de 2012 13:03 > *Para:* [email protected] > *Assunto:* RES: [Pound Mailing List] Re: Bad HTTP response messages in > Google Chrome with Transfer-Encoding: chunked**** > > ** ** > > Try two approaches : “chunkin off” or put the keep alive timeout in 0.**** > > ** ** > > *De:* Dennis Becker [mailto:[email protected] <[email protected]>] > *Enviada em:* terça-feira, 15 de maio de 2012 10:56 > *Para:* [email protected] > *Assunto:* Re: [Pound Mailing List] Re: Bad HTTP response messages in > Google Chrome with Transfer-Encoding: chunked**** > > ** ** > > As of Nginx, this won't work. It only uses HTTP 1.0 if the client forces > HTTP 1.0, otherwise, it uses HTTP 1.1 with Tranfer-Encoding: chunked. No > configuration option.**** > > I don't know how this could be solved for Lighttpd and Apache, but that > doesn't matter if one server system can't change the protocol version.**** > > As far as I could find out, Pound neither could be forced to use HTTP 1.0 > which lacks of opportunities.**** > > On Tue, May 15, 2012 at 3:40 PM, Roberto Geraldo Pimenta Ribeiro Junior < > [email protected]> wrote:**** > > A workaround for you is to disable chuncked transfer encoding from your > backend. > > Enviado via iPhone**** > > > Em 15/05/2012, às 10:09, "Dennis Becker" <[email protected]> escreveu:**** > > One week is gone, no response so far. It would be really nice if I could > get any help with this, because this is really an annoying issue. I'll > checked Opera meanwhile and it has also the same issue as Google Chrome and > stops working on these long polling URLs due to bad HTTP response messages > delivered by pound. ** ** > > ** ** > > ** ** > > Regards,**** > > Dennis**** > > ** ** > > On Wed, May 9, 2012 at 5:42 PM, Dennis Becker <[email protected]> wrote:** > ** > > I have switched my local setup to use HTTP instead of HTTPS so that I can > compare all HTTP Requests and Responses with ngrep. I had side-by-side > terminals opened. The Requests were all ok, Here is the request from > browser to pound:**** > > ** ** > > T 2012/05/09 17:28:25.722352 127.0.0.1:36815 -> 127.0.0.1:8080 [AP]**** > > GET /nginx-poll/?key=abc HTTP/1.1.**** > > Host: example:8080.**** > > Connection: keep-alive.**** > > Cache-Control: no-cache.**** > > If-Modified-Since: Wed, 09 May 2012 15:28:25 GMT.**** > > Pragma: no-cache.**** > > User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, > like Gecko) Chrome/18.0.1025.168 Safari/535.19.**** > > If-None-Match: 0.**** > > Accept: */*.**** > > Referer: http://example.com:8080/.**** > > Accept-Encoding: gzip,deflate,sdch.**** > > Accept-Language: en-US,en;q=0.8.**** > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3.**** > > Cookie: BUNCH_OF_COOKIES.**** > > .**** > > ** ** > > And here is the HTTP Request the pound sends to Nginx:**** > > ** ** > > T 2012/05/09 17:28:25.724359 127.0.0.1:33670 -> 127.0.0.1:81 [A]**** > > GET /nginx-poll/?key=abc HTTP/1.1.**** > > Connection: keep-alive.**** > > Cache-Control: no-cache.**** > > If-Modified-Since: Wed, 09 May 2012 15:28:25 GMT.**** > > Pragma: no-cache.**** > > User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, > like Gecko) Chrome/18.0.1025.168 Safari/535.19.**** > > If-None-Match: 0.**** > > Accept: */*.**** > > Referer: http://example.com:8080/.**** > > Accept-Encoding: gzip,deflate,sdch.**** > > Accept-Language: en-US,en;q=0.8.**** > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3.**** > > Cookie: BUNCH_OF**** > > ** ** > > T 2012/05/09 17:28:25.724371 127.0.0.1:33670 -> 127.0.0.1:81 [AP]**** > > _COOKIES.**** > > host: example.com.**** > > X-Forwarded-For: 127.0.0.1.**** > > .**** > > ** ** > > ** ** > > And now the corresponding responses. First, we start wit the Response of > Nginx:**** > > ** ** > > T 2012/05/09 17:28:45.355341 127.0.0.1:81 -> 127.0.0.1:33633 [AP]**** > > HTTP/1.1 304 Not Modified.**** > > Server: nginx/1.0.14.**** > > Date: Wed, 09 May 2012 15:28:45 GMT.**** > > Content-Type: application/json.**** > > Last-Modified: Wed, 09 May 2012 15:28:45 GMT.**** > > Connection: keep-alive.**** > > Transfer-Encoding: chunked.**** > > Etag: 0.**** > > .**** > > ** ** > > ** ** > > T 2012/05/09 17:28:45.355381 127.0.0.1:81 -> 127.0.0.1:33633 [AP]**** > > 0.**** > > .**** > > ** ** > > As we can see, there is chunk which ends the response.**** > > ** ** > > And here comes the response the pound sends from Nginx to the browser:**** > > ** ** > > T 2012/05/09 17:28:45.355581 127.0.0.1:8080 -> 127.0.0.1:36811 [AP]**** > > HTTP/1.1 304 Not Modified.**** > > Server: nginx/1.0.14.**** > > Date: Wed, 09 May 2012 15:28:45 GMT.**** > > Content-Type: application/json.**** > > Last-Modified: Wed, 09 May 2012 15:28:45 GMT.**** > > Connection: keep-alive.**** > > Transfer-Encoding: chunked.**** > > Etag: 0.**** > > .**** > > ** ** > > ** ** > > As you can see immidiately, there is no chunk which ends this message and > Google Chrome cannot parse the complete response. Due to the fact that > Google Chrome is really strict in parsing chunked response messages, this > issue should be fixed in pound.**** > > ** ** > > ** ** > > ** ** > > On Tue, May 8, 2012 at 9:15 AM, Dennis Becker <[email protected]> wrote:** > ** > > Hi, **** > > ** ** > > we have a setup where pound is the load balancer in front of a NGinx Long > Polling server. I can reproduce an issue where after a long poll ends with > "HTTP 304 not modified", the next HTTP response message is corrupt. You'll > get in Google Chrome messages like this:**** > > ** ** > > 0**** > > ** ** > > HTTP/1.1 200 OK**** > > Server: nginx/1.0.14**** > > Date: Tue, 08 May 2012 05:58:03 GMT**** > > Content-Type: application/json**** > > Last-Modified: Tue, 08 May 2012 05:57:33 GMT**** > > Connection: close**** > > Etag: 0**** > > Transfer-Encoding: chunked**** > > ** ** > > 2159**** > > {"REMOVED_BODY_CONTENT"}**** > > ** ** > > I also have this issue with a Lighttpd behind Pound using chunked encoding. > **** > > ** ** > > Google Chrome is really strict in it's parsing rules for chunked encoding. > See http://code.google.com/p/chromium/issues/detail?id=39206#c12 > **** > > ** ** > > ** ** > > I have found the issue with pound 2.5 but have also the same error with > pound 2.6 and 2.7.**** > > ** ** > > ** ** > > When I use Apache as proxy everything works fine.**** > > ** ** > > -- > Dennis Becker [email protected] > Telefon: +49 (0) 211-63 55 55-97 > Telefax: +49 (0) 211-63 55 55-22 > > sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf > HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois > Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 > > www.sipgate.de - www.sipgate.at - www.sipgate.co.uk**** > > > > **** > > ** ** > > -- > Dennis Becker [email protected] > Telefon: +49 (0) 211-63 55 55-97 > Telefax: +49 (0) 211-63 55 55-22 > > sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf > HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois > Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 > > www.sipgate.de - www.sipgate.at - www.sipgate.co.uk**** > > > > **** > > ** ** > > -- > Dennis Becker [email protected] > Telefon: +49 (0) 211-63 55 55-97 > Telefax: +49 (0) 211-63 55 55-22 > > sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf > HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois > Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 > > www.sipgate.de - www.sipgate.at - www.sipgate.co.uk**** > > > > **** > > ** ** > > -- > Dennis Becker [email protected] > Telefon: +49 (0) 211-63 55 55-97 > Telefax: +49 (0) 211-63 55 55-22 > > sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf > HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois > Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 > > www.sipgate.de - www.sipgate.at - www.sipgate.co.uk**** > -- Dennis Becker [email protected] Telefon: +49 (0) 211-63 55 55-97 Telefax: +49 (0) 211-63 55 55-22 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.at - www.sipgate.co.uk
