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   becker(at)sipgate.de
 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

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 <becker(at)sipgate.de> 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   becker(at)sipgate.de
>  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   becker(at)sipgate.de
 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

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 <becker(at)sipgate.de> 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 <becker(at)sipgate.de> 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   becker(at)sipgate.de
>>  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   becker(at)sipgate.de
>  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   becker(at)sipgate.de
 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

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"
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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<http://127.0.0.1:36815> ->
127.0.0.1:8080<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://127.0.0.1:81> [AP]
_COOKIES.
host: example.com<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://127.0.0.1:33633> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://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<http://127.0.0.1:8080> ->
127.0.0.1:36811<http://127.0.0.1:36811> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>

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 <
rpimenta(at)senado.gov.br> 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" <becker(at)sipgate.de> 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 <becker(at)sipgate.de> 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 <becker(at)sipgate.de>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   becker(at)sipgate.de
>>>  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   becker(at)sipgate.de
>>  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   becker(at)sipgate.de
>  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   becker(at)sipgate.de
 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

I’ve looked at this and the short of it is I can’t reproduce your issue. 
And the fact you’re seeing:
0

HTTP/1.1 200 OK


In your next request leads me to believe pound *did* pass the chunk back to the
client properly, over the connection to the browser.

I whipped up this code:
#!/usr/bin/perl
use HTTP::Daemon;
use HTTP::Status;

my $d = HTTP::Daemon->new(LocalPort => 8660) || die;
while (my $c = $d->accept) {
  print $c->peerhost().":".$c->peerport(),":\n";
  while (my $r = $c->get_request) {
    print_in($r->as_string());
    if ($r->method eq "GET") {
      if ($r->uri->path eq "/chunktst/getme.html") {
        print_out($c,"HTTP/1.1 200 OK\r\nServer: nginx/1.0.14\r\nDate: Wed, 09
May 2012 15:28:45 GMT\r\nContent-Type: text/html\r\nConnection:
keep-alive\r\nTransfer-Encoding: chunked\r\nEtag: 0\r\n\r\n");
                foreach my $chunk ("<html>\r\n","  <head>\r\n", "   
<title>MyTitle</title>\r\n  </head>\r\n  <body>\r\nThis is a ", "test\r\n 
</body>\r\n", "</html>\r\n") {
          print_out($c, unpack("H*",pack("C*",
length($chunk)))."\r\n".$chunk."\r\n");
          $c->flush();
        }
        print_out($c, "0\r\n\r\n");
        $c->flush();
      } elsif ($r->uri->path =~ "^/chunktst/poll.cgi") {
        print_out($c, "HTTP/1.1 304 Not Modified\r\nServer:
nginx/1.0.14\r\nDate: Wed, 09 May 2012 15:28:45 GMT\r\nContent-Type:
application/json\r\nLast-Modified: Wed, 09 May 2012 15:28:45 GMT\r\nConnection:
keep-alive\r\nTransfer-Encoding: chunked\r\nEtag: 0\r\n\r\n");
        $c->flush();
        sleep(1);
        print_out($c, "0\r\n\r\n");
        $c->flush();
        print_out($c, "4\r\ncrap");
      } else {
                my $resp="File not found\r\n";
        print_out($c, "HTTP/1.1 404 Not Found\r\nServer:
nginx/1.0.14\r\nContent-Type: text/plain\r\nContent-Length:
".length($resp)."\r\n\r\n$resp");
      }
    } else {
      my $resp="File not found\r\n";
      print_out($c, "HTTP/1.1 404 Not Found\r\nServer:
nginx/1.0.14\r\nContent-Type: text/plain\r\nContent-Length:
".length($resp)."\r\n\r\n$resp");
    }
  }
  print $c->peerhost().":".$c->peerport()," closed\n\n";
  $c->close;
  undef($c);
}

sub print_in() {
  foreach my $lines ((at)_) {
    my $l = $lines;
    $l =~ s/^/\<\<\< /gsm;
    print $l;
  }
  print "\n\n";
}

sub print_out() {
  my $c = shift((at)_);
  foreach my $lines ((at)_) {
    $c->print($lines);
    my $l = $lines;
    $l =~ s/^/\>\>\> /gsm;
    print $l;
  }
}

If you run it in perl, and connect on port 8660 it’ll do some tests.

I point my browser at http://localhost:8660/chunktst/getme.html

And I get proper responses. (chrome 18.0.1025.162) The page comes up, the data
is intact and correct.

I point my browser at http://localhost:8660/chunktst/poll.cgi?hi
The page loads fine.  But I’ve injected poison (the 4\r\ncrap\r\n) at the end
, so subsequent requests fail.

Now, I point pound URL /chunktst/ at backend 127.0.0.1:8660

I pull up http://localhost/chunktst/getme.html
It works fine

I pull up http://localhost/chunktst/poll.cgi?hi2

It works fine too.

Not only that, but telnetting to localhost 80 and typing:
GET /chunktst/poll.cgi?hi3 HTTP/1.1
Host: localhost


Returns a proper response, with the proper chunked data, WITHOUT the poison at
the end.  This to me verifies pound is sending all the chunks, and ignoring the
invalid chunk at the end, as it should.

Tested w/ my local modified 2.5 branch. (but there’s no chunk encoding
changes in my local branch)

Further, I looked at the chunk handling in stock Pound 2.6’s http.c and
cannot see any issue.

Can you do similar steps in your install and see if your install fails?  If it
does, I’ll want the exact version of pound you’re using so I can use that
same version here.

Joe

From: Dennis Becker [mailto:becker(at)sipgate.de]
Sent: Tuesday, May 15, 2012 9:56 AM
To: pound(at)apsis.ch
Subject: 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
<rpimenta(at)senado.gov.br<mailto:rpimenta(at)senado.gov.br>> 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"
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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<http://127.0.0.1:36815> ->
127.0.0.1:8080<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://127.0.0.1:81> [AP]
_COOKIES.
host: example.com<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://127.0.0.1:33633> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://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<http://127.0.0.1:8080> ->
127.0.0.1:36811<http://127.0.0.1:36811> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>

I Will send you the solution ... wait ….

De: Dennis Becker [mailto:becker(at)sipgate.de]
Enviada em: terça-feira, 15 de maio de 2012 10:56
Para: pound(at)apsis.ch
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
<rpimenta(at)senado.gov.br<mailto:rpimenta(at)senado.gov.br>> 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"
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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<http://127.0.0.1:36815> ->
127.0.0.1:8080<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://127.0.0.1:81> [AP]
_COOKIES.
host: example.com<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://127.0.0.1:33633> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://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<http://127.0.0.1:8080> ->
127.0.0.1:36811<http://127.0.0.1:36811> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>

Give me your “nginx –V”

De: Dennis Becker [mailto:becker(at)sipgate.de]
Enviada em: terça-feira, 15 de maio de 2012 10:56
Para: pound(at)apsis.ch
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
<rpimenta(at)senado.gov.br<mailto:rpimenta(at)senado.gov.br>> 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"
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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<http://127.0.0.1:36815> ->
127.0.0.1:8080<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://127.0.0.1:81> [AP]
_COOKIES.
host: example.com<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://127.0.0.1:33633> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://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<http://127.0.0.1:8080> ->
127.0.0.1:36811<http://127.0.0.1:36811> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>

Try two approaches : “chunkin off” or put the keep alive timeout in 0.

De: Dennis Becker [mailto:becker(at)sipgate.de]
Enviada em: terça-feira, 15 de maio de 2012 10:56
Para: pound(at)apsis.ch
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
<rpimenta(at)senado.gov.br<mailto:rpimenta(at)senado.gov.br>> 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"
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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<http://127.0.0.1:36815> ->
127.0.0.1:8080<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://127.0.0.1:81> [AP]
_COOKIES.
host: example.com<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://127.0.0.1:33633> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://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<http://127.0.0.1:8080> ->
127.0.0.1:36811<http://127.0.0.1:36811> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>

Try this for nginx….
De: Roberto Geraldo Pimenta Ribeiro Junior
Enviada em: terça-feira, 15 de maio de 2012 13:03
Para: pound(at)apsis.ch
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:becker(at)sipgate.de]
Enviada em: terça-feira, 15 de maio de 2012 10:56
Para: pound(at)apsis.ch<mailto:pound(at)apsis.ch>
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
<rpimenta(at)senado.gov.br<mailto:rpimenta(at)senado.gov.br>> 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"
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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<http://127.0.0.1:36815> ->
127.0.0.1:8080<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://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<http://127.0.0.1:33670> ->
127.0.0.1:81<http://127.0.0.1:81> [AP]
_COOKIES.
host: example.com<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://127.0.0.1:33633> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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<http://127.0.0.1:81> ->
127.0.0.1:33633<http://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<http://127.0.0.1:8080> ->
127.0.0.1:36811<http://127.0.0.1:36811> [AP]
HTTP/1.1 304 Not Modified.
Server: nginx/1.0.14.<http://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
<becker(at)sipgate.de<mailto:becker(at)sipgate.de>> 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   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 Telefon:        +49 (0) 211-63 55
55-97<tel:%2B49%20%280%29%20211-63%2055%2055-97>
 Telefax:        +49 (0) 211-63 55
55-22<tel:%2B49%20%280%29%20211-63%2055%2055-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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>



--
 Dennis Becker   becker(at)sipgate.de<mailto:becker(at)sipgate.de>
 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<http://www.sipgate.de> - www.sipgate.at<http://www.sipgate.at>
- www.sipgate.co.uk<http://www.sipgate.co.uk>

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 <
rpimenta(at)senado.gov.br> wrote:

>  Try this for nginx….****
>
> *De:* Roberto Geraldo Pimenta Ribeiro Junior
> *Enviada em:* terça-feira, 15 de maio de 2012 13:03
> *Para:* pound(at)apsis.ch
> *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:becker(at)sipgate.de <becker(at)sipgate.de>]
> *Enviada em:* terça-feira, 15 de maio de 2012 10:56
> *Para:* pound(at)apsis.ch
> *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 <
> rpimenta(at)senado.gov.br> 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" <becker(at)sipgate.de>
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 <becker(at)sipgate.de> 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 <becker(at)sipgate.de> 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   becker(at)sipgate.de
>  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   becker(at)sipgate.de
>  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   becker(at)sipgate.de
>  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   becker(at)sipgate.de
>  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   becker(at)sipgate.de
 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