Re: XMLHttpRequest: Why list HTTP method names

On 10/11/06, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> 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.


Sorry - I don't follow. A little explaining would help. What purpose other
than specifying the semantics of the fields/operations of XHR?

> (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.


I understand. The issue we have in the use case I listed is that there is no
mapping for other options to the programming model exposed to the component
developers.

> 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?


In other words, in order to comply to the requirement to support, say,
DELETE, we will have to come up with what it means for the component. I
could see some use cases, but coming back to the original question, the
wrapped implementation should be able to choose the method support depending
on what makes sense.

Two sum up, there does not seem to be any reason other than some intent of
making implementations support a base set of methods. If the WG feels
strongly about this, instead of saying a MUST or SHOULD, the spec could add
a statement "encouraging" implementations support these base set of methods.

Regards,
Subbu


Best regards, Julian
>
>
>


-- 
------------------------------
http://www.subbu.org