Bug 20491

Summary: XHR sometimes says xhr.status == 204 when it should be 200
Product: WebKit Reporter: Ian 'Hixie' Hickson <ian>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WORKSFORME    
Severity: Normal CC: ap, mrowe, sam
Priority: P2 Keywords: HasReduction
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
URL: http://damowmow.com/playground/bugs/unfiled/010.html

Ian 'Hixie' Hickson
Reported 2008-08-23 01:46:58 PDT
STEPS TO REPRODUCE 1. Load http://damowmow.com/playground/bugs/unfiled/010.html 2. You may need to reload a couple of times. ACTUAL RESULTS 204 204 EXPECTED RESULTS PASS (second XHR's status should be 200) The test page does two XHRs back to back. The first returns: HTTP/1.1 204 No Content Content-Type: text/plain The second returns: HTTP/1.1 200 OK Content-Type: text/plain Testing... It appears that the second time the 204 page is hit, the Content-Type line in the 204 response causes the 204 response to "leak" its status code to the next XHR.
Attachments
Ian 'Hixie' Hickson
Comment 1 2008-08-23 01:49:24 PDT
This test: http://damowmow.com/playground/bugs/unfiled/010-double.html ...runs the test twice back to back (204/200/204/200) so if the problem is caching related this should expose it even without a reload.
Alexey Proskuryakov
Comment 2 2010-05-25 13:48:46 PDT
I cannot reproduce this with Safari 4.0.5 on Mac OS X 10.5.8.
Alexey Proskuryakov
Comment 3 2010-05-25 13:50:29 PDT
Also tested ToT on Tiger.
Note You need to log in before you can comment on or make changes to this bug.