All users were logged out of Bugzilla on October 13th, 2018
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.
-> docshell (or maybe uriloader) has code designed to handle 204 responses. necko doesn't do anything special.
Assignee: darin → adamlock
Component: Networking: HTTP → Embedding: Docshell
QA Contact: httpqa → adamlock
Confirmed using FizzillaMach/2002112607.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Is this still an issue? This worksforme using the 204-returning page from bug 275890.
Assignee: adamlock → nobody
QA Contact: adamlock → docshell
You need to log in before you can comment on or make changes to this bug.