- From: Cameron McCormack <cam@mcc.id.au>
- Date: Sun, 14 Oct 2007 16:31:54 +1000
- To: public-webapi@w3.org
Hi Björn. Bjoern Hoehrmann: > I am not sure what you would be tightening; for example, for getURL it > says "this method will attempt to fetch the resource at that IRI using > the HTTP GET method." and you cannot do that for non-HTTP resources. > It seems you would be significantly extending the feature. Perhaps “tightening the definition to align more closely with what UAs actually allow” would have been a better way for me to put it. > It is also not clear to me whether these changes are motivated by > possible future extensions to XMLHttpRequest to support to accomodate > other protocols (in which case a concern would be what implementations > that simply pass requests on to XMLHttpRequest have to implement on > top of that). It wasn’t specifically motivated by that, no. > If you want to avoid incompatibilities, the appropriate approach would > be to define the functionality in terms of XMLHttpRequest. Acknowledged. > > * Other IRI schemes may be supported for getURL, and if they are > > supported, the method will retrieve the resource identified by > > the IRI. > > It is not clear to me what this means, for example, with respect to the > requirement "User-agents are required to support the gzip content coding > and must decode it before passing it on to the callback." Requirements like that will have to change to say that they are applicable for HTTP requests. > > * Other IRI schemes may be supported for postURL, but only if they are > > functionally equivalent to HTTP (such as itms). > > I am not sure what you mean by "itms" or what "functionally equivalent > to HTTP" means, but this would seem to be an odd restriction; you don't > have it for "getURL", and you can POST to mailto:... or news:... just > fine, as demonstrated e.g. by libwww-perl. XMLHttpRequest also does not > expose any checks, so implementations would probably need additional > logic to ensure they don't improperly support postURL(). By “itms” I mean iTunes Music Store URIs, as mentioned here: http://www.tbray.org/ongoing/When/200x/2003/04/30/AppleWA By “functionally equivalent to HTTP” I mean “is the same as HTTP but happens to use a different URI scheme”, which is closer to the actual wording that would be included (“functionally equivalent” being a bit weasely). POSTing to mailto: and news: URIs, well that is interesting. At least for getURL() it is reasonably clear what to do for non-HTTP URIs (i.e., if the URI is dereferenceable then do so). I think it would be trickier to define what POST means for arbitrary non-HTTP URIs. If you have some wording in mind, please do suggest it. > > * For non-HTTP(S) IRIs, AsyncStatusCallback.status will be set to true > > if the resource was successfully retrieved in full, and false > > otherwise. > > That seems to be rather underdefined. What would happen, for example, > if you successfully retrieve the resource, but there are errors in the > gzip encoding, which implementations must remove? I would say that should be handled in the same way as a resource that wasn’t successfully retrieved. I’ll ensure the actual wording covers cases like this. > Or if the operation > is not a resource retrieval operation (you don't retrieve any resource > if you do a NNTP "POST", if implementations may support that)? If postURL() were changed to allow POSTing to non-HTTP URIs, then it would make sense to handle this in the same way that HTTP 204 responses are handled (which isn’t stated at the moment, but could either be having AsyncStatusCallback.content be null or an empty string). > > * For non-HTTP(S) IRIs, AsyncStatusCallback.contentType will be set to > > null. > > Why would that be? E.g., if you getURL() a data:application/xml,... > surely you'd want to know the type? I agree, it would be useful to be able to get the type from such URIs. -- Cameron McCormack, http://mcc.id.au/ xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
Received on Sunday, 14 October 2007 06:32:14 UTC