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
