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

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

Understood and agreed. In my initial response I was speaking about 
message transmission only; as far as I can tell, a 
servers/intermediaries doing no caching at all are still compliant; so 
caching is truly optional. Yes, I know that's not helpful for the 
implementations we talk about.

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

In the meantime I have followed up over on the HTTP-WG mailing list. 
Yes, spec text like that is confusing, and I think it should be reorganized.

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

Great.

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

I would argue that both the simplest thing and the right thing here is 
not to state anything at all, and let RFC2616bis clarify.

BR, Julian

Received on Monday, 10 December 2007 14:06:05 UTC