Bug 20491
Summary: | XHR sometimes says xhr.status == 204 when it should be 200 | ||
---|---|---|---|
Product: | WebKit | Reporter: | Ian 'Hixie' Hickson <ian> |
Component: | New Bugs | Assignee: | 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
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 | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Ian 'Hixie' Hickson
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
I cannot reproduce this with Safari 4.0.5 on Mac OS X 10.5.8.
Alexey Proskuryakov
Also tested ToT on Tiger.