Re: [XHR] send doesn’t explain what to do when method is GET

Maciej Stachowiak wrote:
>> This is a known issue, see 
>> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i19>.
> 
> It seems that pending resolution of this issue, it's inappropriate to 
> require XMLHttpRequest implementations to sometimes send requests that 
> may be in violation of the RFC.

It's also inappropriate to require implementations not to send the body 
when HTTP allows it. So how about staying silent about it?

>> I don't see why that would be a violation. As far as I can tell, some 
>> people consider it an extension point.
> 
> 9.1.1 "In particular, the convention has been established that the GET 
> and HEAD methods SHOULD NOT have the significance of taking an action 
> other than retrieval."

Yes. I wasn't suggesting otherwise.

> 9.3 "The GET method means retrieve whatever information (in the form of 
> an entity) is identified by the Request-URI."
> 
> Seems to me that processing a GET request should not have any action on 
> the server other than retrieval, and retrieves an entity identified by 
> the Request-URI (and not, for instance, by any possible entity body).
> 
> Also, it seems that if a GET response that varies based on entity-body 
> is allowed at all, it would have to be specified as uncacheable or it 
> would break integrity of caches.

Yes, but I don't see why that would be a problem.

>> It's not clear at all, IMHO, otherwise we probably wouldn't discuss it.
> 
> All right, I will admit that this is unclear (along with many other 
> details of the HTTP protocol).

Ah, consensus :-). Yes, there are many other things in the spec that 
should be improved, and judging from the people who attended last week's 
WG meeting, there's quite a lot of interest across various companies to 
get this done.

>> On the other hand, the inability of a library/client/HTTP stack to 
>> pass a body in GET requests is a clear sign that it special-cases 
>> message passing behavior based on the request method, which would be a 
>> very bad design.
> 
> That doesn't seem right to me. HTTP client special-casing based on 
> request method is required or recommended by the RFC in some cases:
> 
> - For TRACE, it is indisputably mandatory for an http client library to 
> special-case the method (since it MUST NOT send an entity-body).

Hm, no. It means that the client must not send the body, where the 
client consists of a client library and code driving it. It's not clear 
that it's the library's role to enforce this.

> - For GET, HEAD and DELETE, it is unclear based on the current RFC 
> whether the same special-casing is mandatory, forbidden or optional.

No special casing is needed anyway, see above.

> - Responses to OPTIONS, PUT and DELETE are not cacheable, apparently 
> notwithstanding response headers.

We're now talking about caching, and I totally agree that more 
clarifications are required here (I was referring to the actual message 
transmission in my reply).

> - Responses to POST are not cacheable unless explicitly specified by 
> Cache-Control or Expires response headers.
> - Issuing a PUT, POST or DELETE should invalidate cached entities for 
> the corresponding Request-URI.

...see above...

> - For GET, some special semantics are defined for conditional and range 
> headers.

Are you saying that handling of conditionals is different for GET? Pointer?

> ...
>> The HTTP spec defines the message format uniformly across methods 
>> (with the known exception HEAD), and thus I'd recommend to write 
>> implementations accordingly.
> 
> Thanks for the suggestion, however I'm not sure this advice is 
> applicable. And in any case it comes too late to affect the structure of 
> already existing implementations, so does not have much effect on the 
> pragmatic landscape.

It should affect specs that are based on HTTP, such as XHR.

>> So please let the HTTPbis WG worry about how to resolve this issue; 
>> and do not step into areas not owned by this WG.
> 
> The relevant input to this working group as far as HTTP is concerned is 
> the appropriate RFCs. HTTPbis WG members may have useful information on 
> the content of current or future RFCs, but it is certainly within this 
> WGs purview to read and interpret the relevant specifications for 
> ourselves.

Sure.

What I was trying to say (and apparently failed to) was that if *this* 
WG feels there's a problem in RFC2616, the right thing to do is to raise 
this issue over on the HTTPbis working group, and let *that* working 
group discuss it (which, btw, is an IETF WG and thus completely free to 
participate).

BR, Julian

Received on Sunday, 9 December 2007 15:50:20 UTC