Re: [whatwg] XMLHttpRequest readyState==3
David Flanagan wrote: If onreadystatechange is guaranteed to be called only once for readyState 3, then I don't see much point in making responseText available in this state. It seems like it will encourage the use of window.setTimeout() to poll the responseText property looking for new stuff... It looks like Gecko implements an onprogress event handler for this purpose, using an event object of type LSProgressEvent (http://www.w3.org/TR/2002/WD-DOM-Level-3-LS-20020725/load-save.html#LS-LSProgressEvent) That event listener is called each time new data arrives. Maybe that's an alternative to consider?
[whatwg] XMLHttpRequest
Ian -- Thanks for your comment on my blog, drawing my attention to the WhatWG spec for XMLHttpRequest. I like the fact that you've explicitly stated that getResponseHeader/s() and responseText return whatever is available so far in readyState 3. On a related note, your spec is unambiguous that onreadystatechange() is never to be called unless readyState actually changes. It may be myth, but I was under the impression that existing implementations might call onreadystatechange repeatedly for state 3, to indicate download progress... This behavior (if it is actually implemented) is useful to display a loading... animation and give the end user feedback about the status of a long download. Did you consider this and purposely reject it? I know that the common XMLHttpRequest use case is for small downloads, so this would not be all that commonly used... But if you decide to allow multiple calls to the event handler for state 3, I suppose it would be useful to add a bytesReceived property to the object... David Flanagan
[whatwg] XMLHttpRequest readyState==3
Ian, This is a followup to my previous message. If onreadystatechange is guaranteed to be called only once for readyState 3, then I don't see much point in making responseText available in this state. It seems like it will encourage the use of window.setTimeout() to poll the responseText property looking for new stuff... If you think that programmers might be interested looking at partial responses, then maybe you should call onreadystatechange each time a new chunk of the response becomes available. Furthermore, the ambiguity of the headers is a little problematic. If you query a header and get null in response, you don't know if it is because that header was not in the first packet and is yet to come or if it simply does not exist. I suppose you could check the length of responseText to determine whether all headers have been downloaded yet or not. But I'd say that there ought to be some more explicit way to determine whether all headers have been received. If responseText is being parsed out and made available on readyState 3, then it seems to me that you ought to just go ahead and say that state 3 means that all headers have been received and that the response body is being loaded... Here's something else to think about: if the server's entire response arrives in a single packet, can the UA skip state 3 and jump directly to state 4? Or is there a guarantee that onreadystatechange will be invoked for each state? David
Re: [whatwg] XMLHttpRequest: should UA pretend a 304 response is a 200?
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 server between the web application and the web for XMLHttpRequest purposes. This would mean using the instructions of the HTTP protocol specification for the interaction between the script and its environment. 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). That's an interesting point of view. I'm quite convinced by Jim's reference to systems he has implemented, but if we use the HTTP spec for communicating between the JS app and the UA perhaps we can use headers to have it both ways depending on the cache-control and/or pragma instructions? I have to read the HTTP spec's cache part much more closely before I can give any concrete suggestions though.. -- Hallvord Reiar Michaelsen Steen http://www.hallvord.com/
Re: [whatwg] XMLHttpRequest: should UA pretend a 304 response is a 200?
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 against this, if the resource is cacheable, then I'm happy that what comes back could be a 200 or a 304, all my implementations, and indeed any situation I can imagine where knowing a 304 on the client is for resources that are must-revalidate, if it's just naturally cacheable, I'm not sure the fact it's been checked for freshness is relevant. Consider a cache which updates itself every 20 minutes for a resource (without any request from the user agent), first time it gets a 200, then each of the next requests it gets a 304, when the user agent then makes a request to it, it's going to return the resource with 200, that's reasonable. So yes, I would be happy with the above interpretation, as long as a specific request from the script, results in that value being what's actually returned. I'm happy that cache itself operates seperately and simple freshness checks for a resource could stay as a 200 certainly. The arguments make sense. Cheers, Jim.
Re: [whatwg] XMLHttpRequest: should UA pretend a 304 response is a 200?
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. Suggestion withdrawn :) -- Hallvord Reiar Michaelsen Steen http://www.hallvord.com/
[whatwg] XMLHttpRequest: should UA pretend a 304 response is a 200?
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 malfunction. Clearly it will cause subtle, hard-to-debug bugs in web apps if they look for a status 200 and the response actually is a 304. The UA makes the document available, of course, so why not fake the request and re-play the original response? It may also be an issue with getResponseHeader / getAllResponseHeaders because the server may not send the expected headers with a 304. So, should we not tell the JavaScript that a 304 response was returned, but show the original response including headers? Views? -- Hallvord Reiar Michaelsen Steen http://www.hallvord.com/
Re: [whatwg] XMLHttpRequest: should UA pretend a 304 response is a 200?
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 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..? 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). If apps are tested mainly with IE and somewhat superficially in other browsers, these minor browsers will be penalised for their caching. I think faking 200 would be in the interest of smaller browsers 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..) -- Hallvord Reiar Michaelsen Steen http://www.hallvord.com/
Re: [whatwg] XMLHttpRequest: should UA pretend a 304 response is a 200?
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 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.
Re: [whatwg] XMLHttpRequest: getAllResponseHeaders
Hallvord Reiar Michaelsen Steen wrote: FF actually throws an exception if you try to read a non-existing header. The spec recommendation is returning an empty string, which seems better. FWIW, in FF 1.1 that will return null (https://bugzilla.mozilla.org/show_bug.cgi?id=276705) smime.p7s Description: S/MIME Cryptographic Signature
[whatwg] XMLHttpRequest abort
http://www.whatwg.org/specs/web-apps/current-work/#scripted-http abort Cancels any network activity for which the object is responsible and returns readyState to 0 (Uninitialised). If the connection is synchronous, browsers differ: FireFox aborts the connection if abort() is called from a timeout thread, IE6 and Opera 8 do not. FireFox's behaviour lets script authors use any timeout they prefer, thought using a setTimeout may be a bit clunky. Can we standardise this behaviour? -- Hallvord Reiar Michaelsen Steen http://www.hallvord.com/
Re: [whatwg] XMLHttpRequest: getAllResponseHeaders
On 22 Jun 2005 at 10:24, I wrote: getAllResponseHeaders() If the readyState attribute has a value other than 3 (Receiving) or 4 (Loaded), returns null. 1) This seems a bit inconsistent since the spec says that accessing status and statusText out of order should cause exception. 2) This is not what UAs actually do. IE and FF throw an exception and Opera returns an empty string. Same applies to getResponseHeader, except that the spec actually says return empty string rather than null here. FF actually throws an exception if you try to read a non-existing header. The spec recommendation is returning an empty string, which seems better. -- Hallvord Reiar Michaelsen Steen http://www.hallvord.com/
[whatwg] XMLHttpRequest - Web App 1.0 (2005-06-14)
Hi, I've sent a comment on XMLHttpRequest to the WHATWG mailing list, but maybe this is a more appropriate place. I think one should not be allowed to call open() in all readyStates (as the current specification suggests). This initialization of the request makes sense only in three states (IMHO): 0 (first init or re-init after abort) 1 (re-init after a successful open()) 4 (re-init after completed request) So, the following statement should be added to the specification for open(): If the readyState attribute has a value other than 0 (Uninitialized), 1 (Open) or 4 (Loaded), raises an exception. [...] bye, Thomas -- iCab Internet Browser - Worldwide Your Guide http://www.icab.de mailto:[EMAIL PROTECTED]
