On 4 Jul 2005 at 17:18, I wrote:
Thanks for sharing your implementation experience regarding status
304. Suggestion withdrawn
This is just summarising some discussions at Opera for documentation
and consideration :-)
Some people feel we should consider the UA a sort of caching proxy
On 7/8/05, Hallvord Reiar Michaelsen Steen [EMAIL PROTECTED] wrote:
This may imply that a client with a cached document
should return a status 200 when the requested document matches one in
the cache (whether or not the UA has checked with the server if the
resource is current).
I wouldn't be
On 3 Jul 2005 at 23:15, Jim Ley wrote:
(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
Thanks for sharing your implementation experience regarding status
304.
This suggestion is based on a real-world web app problem. The app
requested a file and checked if the status was 200 in the
onreadystate event handler. However, sometimes the browser would have
the file cached and send a conditional request, and giving the app
the 304 response caused it to
On 3 Jul 2005 at 21:30, Jim Ley wrote:
So, should we not tell the JavaScript that a 304 response was
returned, but show the original response including headers? Views?
Absolutely not!
Thanks for your opinion and arguments :-)
I sort of think it is a bad idea too. However..
It's trivial to
On 7/3/05, Hallvord Reiar Michaelsen Steen [EMAIL PROTECTED] 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
