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
