Subbu Allamaraju schrieb:
On 10/11/06, *Julian Reschke* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
