Re: Support for compression in XHR?
On Sep 11, 2008, at 22:59, Jonas Sicking wrote: Wouldn't a better solution then be that when the web page sets the flag on the XHR object the browser will always compress the data? And leave it up to the web page to ensure that it doesn't enable capabilities that the web server doesn't support. After all, it's the web page's responsibility to know many other aspects of server capabilities, such as if GET/POST/DELETE is supported for a given URI. This is the approach I've taken with Validator.nu. Validator.nu support gzipped request bodies. If someone reads the docs for the Web service API so that they can program client code for the service, they should notice what the documentation says about compression. There is, though, the problem that now compression support is part of the published API as opposed to being an orthogonal transport feature, so removing incoming compression support from Validator.nu (e.g. if bandwidth were abundant and CPU were the bottle neck) would break existing clients. This is not a problem with same-site XHR, though, when the same entity controls the server and the JS program performing the requests and can update the JS program immediately. (Validator.nu also advertises Accept-Encoding: gzip via OPTIONS, but I'm not aware of any client automatically picking it up from there.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
[widgets] update death of the etag attr
Hi All, I've dropped the etag attribute from the update element in the Widget Packaging spec as I deemed it too difficult to use in practice (and mostly redundant). It is also unnecessary as updates will be handled through Update Description Documents as defined in the Updates spec (and not by pointing to widget packages on the Web). I will try to have the Update spec ready for FPWD by the end of today. Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] update death of the etag attr
Hi Marcos, On Fri, Sep 12, 2008 at 5:46 AM, Marcos Caceres [EMAIL PROTECTED] wrote: Hi All, I've dropped the etag attribute from the update element in the Widget Packaging spec as I deemed it too difficult to use in practice How so? (and mostly redundant). It is also unnecessary as updates will be handled through Update Description Documents as defined in the Updates spec (and not by pointing to widget packages on the Web). I will try to have the Update spec ready for FPWD by the end of today. That seems a tad overengineered to me. Have implementors bought into it? It seems to me that the etag solution is the low hanging fruit here. Mark.
Re: Support for compression in XHR?
Jonas Sicking [EMAIL PROTECTED] wrote: This at the cost of the overhead of always making an OPTIONS request before attempting compression. Only if you haven't seen the server before - and in the vast majority of cases, you will have. I wouldn't suggest sending it every time, because that would be clearly daft. Typically, HTTP clients need to maintain notes on servers if they want to work optimally with them anyway. Whether the server supports compression via gzip and/or deflate would just be another bit of information that the client could collect. -- Stewart Brodie
RE: [xmlhttprequest2] timeout and JSON
Ah, so it sounds like timing out behaves very similarly to abort() being called? Does onreadystatechange fire since readystate changes to 0? And does this happen before or after ontimeout is fired? I guess IE doesn't have an abort event on the XHR object (is this correct?) so the relation between ontimeout and onabort is undefined as far as the IE implementation goes. Onreadystate change is updated to 0 but does not fire for 0. We don’t have an abort event on XHR object (of course, abort exists) so onabort currently is undefined. -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2008 8:32 PM To: Sunava Dutta Cc: Anne van Kesteren; WebApps WG; Gideon Cohn; Zhenbin Xu; IE8 Core AJAX SWAT Team Subject: Re: [xmlhttprequest2] timeout and JSON Sunava Dutta wrote: I absolutely agree that it would rock if we could use the MS implementation. Thanks Jonas. As always, appreciated. Answers to your question What happens if there is a timeout in that state? 1) .readystate is set to 0 .status is set to 0 .responseXML is set to null .responseText is set to 2) All properties are left as is. 3) Something else (Profit?) Essentially, timeout has the effect that is similar to 1). Infact, design wise is intended to have the same effect although a few superficial differences exist. What 1) seems to ask for is resetting the object, which is what IE8 does. Readystate is set to 0, there are a few differences in IE's (8 and legacy) support for the existing XHR syntax, and those are reflected in the values of the properties when they are accessed in readystate 0 and corresponding exceptions thrown. Any changes to a future release of IE to bring those inline with the XHR spec would remedy the differences. These are: When ontimeout fires: • Getting responseText throws an exception: “The data necessary to complete this operation is not yet available” • Getting responseXML throws an exception: “Unspecified error.” • Getting status throws an exception: “Unspecified error.” Ah, so it sounds like timing out behaves very similarly to abort() being called? Does onreadystatechange fire since readystate changes to 0? And does this happen before or after ontimeout is fired? I guess IE doesn't have an abort event on the XHR object (is this correct?) so the relation between ontimeout and onabort is undefined as far as the IE implementation goes. / Jonas
