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

Re: XMLHttpRequest: Why list HTTP method names

From: Subbu Allamaraju <subbu.allamaraju@gmail.com>
Date: Wed, 11 Oct 2006 13:27:41 -0600
Message-ID: <e3f21b1a0610111227h49fa1126w7ef84a9534bdc4f2@mail.gmail.com>
To: "Web APIs WG (public)" <public-webapi@w3.org>
>
> Well, the "MUST" is so that clients can rely on a certain set of methods
> to be supported. The "SHOULD" is to encourage implementers to do the
> IMHO right thing, meaning to support arbitrary methods.
>
> > That should be the responsibility of specifications layered on top of
> > XMLHttpRequest. For example, a specification talking about
> > XMLHttpRequest for some arbitrary user-agent device might want to say
> > that such a device MUST support GET and POST. Another specification
> > might require support for some other method.
>
> I have a hard time understanding why that would make a difference. Do
> you have a concrete use case where it's harder to implement FOOBAR than
> POST?


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.

(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 implementation would not be able to conform to this
requirement. I hope this is a concrete-enough example for my argument.

Regards,
Subbu


On 10/11/06, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> Subbu Allamaraju schrieb:
> > Really?
> >
> > What I'm trying to understand is that why is it the responsibility of
> > the XMLHttpRequest spec to say that certain specific methods MUST be
> > supported.
>
> Well, the "MUST" is so that clients can rely on a certain set of methods
> to be supported. The "SHOULD" is to encourage implementers to do the
> IMHO right thing, meaning to support arbitrary methods.
>
> > That should be the responsibility of specifications layered on top of
> > XMLHttpRequest. For example, a specification talking about
> > XMLHttpRequest for some arbitrary user-agent device might want to say
> > that such a device MUST support GET and POST. Another specification
> > might require support for some other method.
>
> I have a hard time understanding why that would make a difference. Do
> you have a concrete use case where it's harder to implement FOOBAR than
> POST?
>
> Best regards, Julian
>



-- 
------------------------------
http://www.subbu.org
Received on Wednesday, 11 October 2006 19:27:56 GMT

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