183407 - If web server returns HTTP result code 204 (no content), the next page load fails.

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Chris Buxton]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130

At the bottom of the knowledge base article referenced above is a poll about
whether the article is useful. If you click on either button, the database gets
updated and the server returns result code 204 in the HTTP header, instead of
the usual 200, 300, or 404. This result is supposed to tell the browser that
there's no content at that URL.

The next link the user tries to load, fails - blank white window. Reload and the
proper page appears. It's like the "no content" expectation is mistakenly
applied to the following page load.

Reproducible: Always

Steps to Reproduce:
1. Go to the URL specified above.
2. Click on either Yes or No button at bottom.
3. Click on any link on the page. See the problem.
4. Click on the browser's Reload button.

Actual Results:  
The first attempt to load the subsequent page fails. The reload attempt succeeds.

Expected Results:  
Both attempts should have succeeded. In other words, after receiving the 204
result, the following page load should not be affected.

Comment 1

[Darin Fisher]

-> docshell (or maybe uriloader) has code designed to handle 204 responses. 
necko doesn't do anything special.

Comment 2

[Greg K.]

Confirmed using FizzillaMach/2002112607.

Comment 3

[Alfred Morgan]

here is the TCP process 
Packet 1 - reqest
GET /vote.html?vote=Yes HTTP/1.1

Packet 2 - Response
HTTP/1.1 204 No Content
Content-length: 60

Packet 3 - Continuation
HTTP Continuation packet containing 60 bytes and the content is various carrige
returns and tabs (0x0D 0x09) totaling up to 60 bytes.

I have seen this problem when a continuation packet comes back. 
The data from the continuation packet seems to be inserted at the beggining of
the buffer where the header and content of the next request goes into thus
messing up when it comes time to parse and identify the contents of the buffer.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Is this still an issue?  This worksforme using the 204-returning page from bug
275890.