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

On Dec 9, 2007, at 7:50 AM, Julian Reschke wrote:

> Maciej Stachowiak wrote:
>>>
>>> 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.

All right, it would be an plausible library design to allow sending of  
bad requests. Personally I think many kinds of bad requests should be  
disallowed or corrected by the library. I would consider it very bad  
design for a library to let a client application send an incorrect  
Content-Length, particularly if it is the client library's  
responsibility to manage persistent connections. I think my point is  
just that special-casing certain request types is not obviously wrong,  
as you said, and so the fact that behavior is different

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

Caching most certainly affects the message transmission behavior of a  
caching client library (which is what most browser-hosted  
XMLHttpRequest implementations would use).

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

I honestly couldn't understand which aspects were meant to apply only  
to GET and which to all methods, so I'll withdraw this example. The  
discussion of GET has an extended discussion of how some headers make  
it a "conditional GET" or "range GET" which is lacking for the other  
methods, but the prose describing those headers is not clear about  
their applicability. Section 14.25 describing If-Modified-Since sounds  
like it applies to all methods, but also specifically describes the  
behavior for GET.


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

I agree, and actually I am now encouraged to raise issues with the  
HTTPbis WG about things in the spec that seem unclear.

I think my bottom line is the same as Boris's, I would like to see the  
spec allow XHR implementations not to send GETs with an entity-body.

Regards,
Maciej

Received on Monday, 10 December 2007 02:54:07 UTC