Re: XMLHttpRequest: Why list HTTP method names

Subbu Allamaraju schrieb:
> On 10/11/06, *Julian Reschke* <julian.reschke@gmx.de 
> <mailto: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?

One of the purposes of an API spec is to establish a set of semantics 
generic clients can rely on.

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

So why exactly are you pretending to do HTTP then?

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

XmlHttpRequest is an API for submitting HTTP requests. In that, it 
SHOULD NOT be restricted to specific verbs. Now if the origin server 
supports only a specific set, that's fine. But that's a distinct 
component. A server that can't DELETE is free to return an HTTP status 
of - for instance - 405 or 501.

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

I'm still not sure whether you're talking about an XmlHttpRequest 
component or a server. A server is free to reject any request it wants, 
and RFC2616 specifies how to do that. The XmlHttpRequest component 
should be able to forward any request the clients sends to a server. 
There's no point in limiting the set of request methods in this 
component (except for *certain* security issues).

Best regards, Julian

Received on Wednesday, 11 October 2006 21:48:45 UTC