W3C home > Mailing lists > Public > public-webapi@w3.org > October 2006

Re: XMLHttpRequest: Why list HTTP method names

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 11 Oct 2006 21:44:52 +0200
Message-ID: <452D49B4.9030409@gmx.de>
To: Subbu Allamaraju <subbu.allamaraju@gmail.com>
CC: "Web APIs WG (public)" <public-webapi@w3.org>

Subbu Allamaraju schrieb:
 > Few points -
 >
 > (a) I don't think the question is whether it is hard to implement a 
certain method or not. It certainly is possible to implement. I'm trying 
to find the rationale.
 >
 > (b) IMO, XHR spec is concerned about specifying the semantics of what 
happens when a given implementation does not understand/support a 
particular method - this is correctly addressed by specifying that it 
should throw a SYNTAX_ERR. But saying anything beyond this would be 
limiting.

Of course it's limiting, but I would say this is on purpose.

 > (c) We're considering designing wrapper implementations of 
XMLHttpRequest (e.g. an implementation of XHR in script wrapping a 
native XHR object) to solve some use cases related to UI aggregation 
(e.g. apps aggregating UI components - portlet being an example of a UI 
component). However, in this case, one of the issues we find is the need 
to support methods other than GET and POST - there is no semantic 
mapping of HEAD, OPTIONS etc in this use case, and so a wrapped

HEAD ist the same as GET, expect that there is no response body. If you 
can do GET, you can do HEAD.

 > implementation would not be able to conform to this requirement. I 
hope this is a concrete-enough example for my argument.

I'm not sure I follow. XHR is a component that enables user agents to do 
HTTP. I can see why a *server* wouldn't implement DELETE (for instance), 
but why that component?

Best regards, Julian
Received on Wednesday, 11 October 2006 19:45:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:56 GMT