Bug 11227 – REGRESSION: Header is shown on top of page, intermittently

• Component: Page Loading
• Status: RESOLVED INVALID

Load the above url. If nothing appears above the Pricerunner logo, try changing one of the filtering options in one of the dropdowns down to the left. A new page now loads. I often see what I think is the http header rendered above the Pricerunner logo when I change the filtering options. Reloading the page once or twice seems to fix the problem every time.

All this using nightly r16878.

[Mark Rowe (bdash)]

Created attachment 11009 [details]
Script demonstrating bug in server HTTP implementation.

[Mark Rowe (bdash)]

I took at look at the HTTP transaction between Safari and the server and noticed an oddity:  the length of data specified in the Content-Length header for the CSS file does not match the length of data transmitted.  This leads to Safari treating the extra data as the response header for the following request.  The attached Python script demonstrates this difference.  I was also able to reproduce the problem from the command-line using "curl".  Notice how the closing '*/' on the CSS comment that shows up as extra body data in the Python script is missing from the curl output?

I'm very tempted to mark this as invalid as it's clearly due to the server violating the HTTP specification, but as I can't cause shipping Safari to include the '*/' as the beginning of the next response I figure that it must be somehow ignoring this extra data.
 

Output of Python script:
bdash:~ mrowe$ python test-pricerunner.py 
HTTP/1.1 200 OK
Date: Tue, 10 Oct 2006 02:53:21 GMT
Server: Apache
Set-Cookie: prfoundry2=1167; Expires=Tue, 10-Oct-2006 03:28:21 GMT; Path=/
Set-Cookie: JSESSIONID=D264DC19C0928E8CE97D4DC71B00E35E; Path=/
Set-Cookie: prss=2116711604488011195638402; Path=/
X-Session: 2116711604488011195638402 @ D264DC19C0928E8CE97D4DC71B00E35E
Set-Cookie: PR_SESSIONSOURCE=-%23-%23-%23-%23-%231160448801%23-%23-; Path=/
Set-Cookie: lastRedirect=; Path=/
Expires: Tue, 10 Oct 2006 03:53:21 GMT
Last-Modified: Tue, 10 Oct 2006 02:53:21 GMT
Cache-Control: must-revalidate, max-age=3600
Content-Type: text/css;charset=UTF-8
Content-Length: 35419
Connection: close

Expected 35419 bytes of content, got 35424.
Extra body data was: '1 */\n'
bdash:~ mrowe$ 


Curl output:
bdash:~ mrowe$ curl -s "http://se.pricerunner.com/style.css" | xxd | tail -n 4
0008a20: 0a2f 2a20 454e 4420 6772 6565 6e20 7461  ./* END green ta
0008a30: 6220 666f 7220 576f 726c 6420 6375 7020  b for World cup 
0008a40: 3230 3036 2c20 7570 6c6f 6164 6564 2062  2006, uploaded b
0008a50: 7920 4964 6120 3036 3035 33              y Ida 06053
bdash:~ mrowe$ 

[Mark Rowe (bdash)]

After further testing, this definitely happens in shipping Safari/WebKit.  It can be much more noticable too, as it tends to happen for both the main page and the top iframe containing the logo at once.  In both cases the symptoms are identical:  a "/*" and the HTTP response headers are prefixed to the rendered content.  I believe that the reason that it doesn't always occur is related to how the underlying network frameworks choose which TCP connection to use for the request.  If it uses whichever was last used for the CSS file that triggers the servers Content-Length bug then the rendering issue will occur.  If that connection has timed out and been closed, or another connection is selected, then the issue will not occur.

[Alexey Proskuryakov]

I think it still makes sense to file a Radar bug - after all, Firefox doesn't seem to have this problem.