Re: don't use POST for big GET [was: Dictionaries in HTML ]

> I'm not quite sure how/why this got added to the HTML-WG list as a cross
> post but since I'm not positive that Dan Connolly and Gavin Nicol who have
> commented on thread are on the http-wg list, I'll leave it where it is .... 

We're cross-posting this between HTML-WG and HTTP-WG because the
HTML-WG's document (sections 8.2.2 and 8.2.3 RFC 1866) says things
about the semantics of GET and PUT in HTTP that the HTTP-WG's
(draft-ietf-http-v1*-spec-*.txt) documents do not. 

RFC 1866 8.2.2 & 3 say that GET has no side effects and POST does,
while the only mention of "side-effects" in
draft-ietf-http-v10-spec-04.txt is

# Naturally, it is not possible to ensure that the server does not
# generate side-effects as a result of performing a GET request; in 
# fact, some dynamic resources consider that a feature. The important
# distinction here is that the user did not request the side-effects,
# so therefore cannot be held accountable for them.

So, I was looking at the HTTP drafts, and forgot that the HTML RFC
made a stronger association between GET/PUT and
no-side-effects/side-effects.

I guess that the operative question now is whether most proxy servers
pass on the body of GET requests if they have them. And if so, do they
consider the body part of the cache key? (Seems unlikely).

Is there any ambiguity if a GET has an entity body as well? I mean,
are there headers that might be ambiguiously request headers and
entity headers? (I guess accept vs. content-type, accept-language vs
content-language, but I'd want to go down the list and make sure.)

Received on Sunday, 4 February 1996 18:17:24 UTC