[whatwg] XMLHttpRequest: should UA pretend a 304 response is a 200?

[Jim Ley]

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.

Cheers,

Jim.