XMLHttpRequest: status 200 (OK) reported instead of 304 (Not modified)

RESOLVED INVALID

Status

()

RESOLVED INVALID
12 years ago
12 years ago

People

(Reporter: wingyung, Unassigned)

Tracking

1.8 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Even when a server responds to a XMLHttpRequest with status 304, the status property is 200. I want to be able to take additional action if the property is 200 (which should signify that the XMLHttpRequest fetched something that has been modified).

Reproducible: Always

Steps to Reproduce:
1. Create a XMLHttpRequest that hits a URL that returns status 304.
2. Get the status of the XMLHttpRequest


Actual Results:  
The status was 200.

Expected Results:  
The status should be 304.
Assignee: nobody → xml
Component: General → XML
Product: Firefox → Core
QA Contact: general → ashshbhatt
Version: unspecified → 1.8 Branch
Bug 305420 would seem to indicate that this used to work, at the very least. Are you sure the server is responding with a 304?

A malformed response status will also result in a status==200, could that be the problem?

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/protocol/http/src/nsHttpResponseHead.cpp&rev=1.42.2.1#166
(Reporter)

Comment 2

12 years ago
Thank you for the quick response.

I'm using the LiveHTTPHeaders Firefox extension to view the headers.

The status line reported is: 

HTTP/1.x 304 Not Modified

(In reply to comment #1)
> Bug 305420 would seem to indicate that this used to work, at the very least.
> Are you sure the server is responding with a 304?
> 
> A malformed response status will also result in a status==200, could that be
> the problem?
> 
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/protocol/http/src/nsHttpResponseHead.cpp&rev=1.42.2.1#166
> 

Comment 3

12 years ago
does this happen if you don't have livehttpheaders installed? i've begun to distrust this creature, i'd suggest temporarily testing w/o it, or installing a logging proxy (there's one written in java which isn't too bad if you don't look at it for more than a few minutes).
(Reporter)

Comment 4

12 years ago
Created attachment 227687 [details]
test html file

When I click the button, "status 200" gets printed out, never "status 304".
cache is transparent to its users, this is invalid IMO. (in 1.0.x XMLHttpRequest accidentally didn't use the cache, so the cache entry didn't mess with the server-sent status)

Comment 6

12 years ago
yeah, the current behavior is valid.  it's not a bug that you can't know when the item was taken from the cache vs. being fetched over the network.  at most, this is a feature request, which should be taken up with the w3c (webapi-public@w3.org)
(Reporter)

Comment 7

12 years ago
thanks for everyone's responses.

whether this is a bug or not sounds like it's up for debate - the web server returns status 304 and the XMLHttpRequest says that the status is 200. not sure whether the 304 response should be reinterpreted as 200.

i am interested in this because i'd like to be able to run some additional requests only if the status of the first GET is 200. 

Comment 8

12 years ago
With the patch from bug 331825 you can work around this by setting the if-modified-since header field.
->INVALID per comment 5, 6. Also workaround is available per comment 8.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.