W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

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

From: Larry Masinter <masinter@parc.xerox.com>
Date: Sun, 4 Feb 1996 14:24:38 PST
To: connolly@beach.w3.org
Cc: dwm@shell.portal.com, html-wg@w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <96Feb4.142442pst.2733@golden.parc.xerox.com>
> Larry: please don't recommend that folks use POST for query operations,
> nor use GET for operations with non-trivial side effects.

Dan, if the 'query' contains Japanese characters, there is no other
useful way to denote the charset of the query characters. To deal with

1) We could modify the specification of HTML processing such that
<FORM METHOD=GET ...> forms might code the character set of the user's
typed input for each field, but this would be an incompatible change,
in that old servers would get new content.

2) We could modify GET so that the query could be contained in GET
body instead of the URL, and denote the character sets in the body
(using multipart-form-data as if it had been put). This is an
incompatible change, too.

3) We can use POST for queries, but note that POST values can be
cached if the response says that the value is cachable. This is a
compatible change, in that old caches will not cache data they could
cache, but new caches could cache that data.

> The problem is that the deployed base of HTTP servers don't handle GET
> requests with "very long" URLs. (What's the magic number? 1024 or
> something?)

This is also a problem, and should be dealt with anyway; either HTTP
should give a limit to the selector string it employs or make it clear
that there is no effective limit.

> I suggest HTTP be extended to include a GET-like method where
> large amounts of query data can be sent in the body of the request.
> For example:

I would conjecture that the only difference between your proposed new
method and POST is in the default caching behavior.
Received on Sunday, 4 February 1996 14:28:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC