[whatwg] XMLHttpRequest: should UA pretend a 304 response is a 200?
jim.ley at gmail.com
Sun Jul 3 15:15:55 PDT 2005
On 7/3/05, Hallvord Reiar Michaelsen Steen <hallvord at hallvord.com> wrote:
> On 3 Jul 2005 at 21:30, Jim Ley wrote:
> > It's trivial to work around
> That is obvious. However, *will* people work around it, or will the
> browser that is better at caching documents be at a disadvantage
> because web apps will mysteriously appear broken to the end user..?
XMLHTTP in IE is fully wired into the cache, and works appropriately,
I can't see how the behaviour will differ in different caching
scenarios in any case. IE also returns the exact status code recieved
from the server.
> I don't think IE ever sends a conditional request for a document
> requested via XMLHttpRequest (I don't know every corner of the HTTP
> caching spec though).
It does if the cache is appropriately configured.
> I think faking 200 would be in the
> interest of smaller browsers
I don't see how hobbling smaller browsers helps them in any way. I
also certianly don't see the point in writing a specification just for
smaller browsers, but we've discussed that before.
> and make life simpler for JS authors
> under most conditions (I don't see much of a use case for wanting to
> know about the 304 response..)
I've deployed a number of systems that rely on getting a 304 response
to the xmlhttp request object - Generally the client has been polling
a server for the state of a remote thing (the example most recently in
my mind was the temp of a freezer) and if it's not changed since the
last response, then I quite rightly send a 304, and test for it on the
client, it was an embedded IE solution, and it worked fine in IE.
More information about the whatwg