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

On Sun, 4 Feb 1996, Larry Masinter wrote:

> Since both ways of representing queries-- (GET with ? in URL) vs.
> (POST with multipart-form data) have the same default a priori caching
> behavior (i.e., don't cache, results are unlikely to be in cache), how
> is the example a differentiator as to which is a better representation
> for query requests?

The GET/POST difference has to do with side-effect.  The '?' 
operational behavior has mostly to do with a decision that the value
of caching a search request is minimal but proably not void.
A ? on GET does not alter the basic rule re. side-effects.
 
> > At best, to redefine long understood semantics of GET and POST would 
> > cause the country and its users harship and frustration.
> 
> But there is no distinction in the "long understood semantics" (well,
> not really semantics but operative behavior) between "GET with ? in
> URL" and "POST", so choosing POST over "GET with ? in URL" shouldn't
> cause anyone any additional "hardship or frustration". The "hardship
> or frustration" is a bit of hyperbole in any case; the optimization is
> that for non-cachable requests, it would not send the request up the
> hierarchy in a hierarchical cache setup.

How much hyperbole and how much reality relates to what the cache latency is
for a request which can't be satisified by any cache.

> 
> > A new method or redefining (I read the current HTTP drafts either way
> > on the issue of content with GET) GET seems to provide more compatibility.
> 
> The issue of "compatibility" is not "compatibility with current
> drafts" but "compatibility with current practice" for which the
> current draft (only one for HTTP/1.0) in an attempt to capture.



> 
> > Depending on existing proxies and how they might now handle GET with
> > content-length != 0, this might just boil down to an issue between the
> > sending User Agent and the server and not require WWW wide deployment before
> > it can be used in applicationas between cooperating client/server pairs.
> 
> It's not just proxies, it's servers. At least my reading of the source
> code of the CERN server (/WWW/Daemon/Implementation/), plexus seem to
> indicate that they just throw away the data after a GET, and don't
> even pass it along to CGIs.

I restrict my basic concern to caches because they are almost totally outside
of the control of both the application user and application provider.
I believe that for the provider who needs the improved behavior, the
server could be updated. That would be a moot point of the proxy doesn't
pass on the data.

> didn't implement RFC 1867 at least for ASCII data.
> 
> So, I don't know why I shouldn't recommend that form designers use
> <FORM METHOD=POST ENCTYPE=multipart/form-data> for forms if they're
> willing to accept non-8859-1 encodings.

Well, I would note that your recommendation is contrary to the HTML RFC's
description of GET and POST.

Dave

Received on Sunday, 4 February 1996 17:50:11 UTC