- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 05 Jan 96 11:07:02 PST
- To: "David W. Morris" <dwm@shell.portal.com>
- Cc: HTTP Caching Subgroup <http-caching@pa.dec.com>
So I'm still trying to understand why the application would choose
POST and not GET. If the concern is transfer methodology, that is
send via URL or entity body, perhaps that should be addressed more
explicity by a new method or FORM attribute.
That (transfer of the query parameters) seems to be one problem
area. For example, Digital's Altavista search engine encodes
the user's query as a lengthy URL in a GET request. We know
of at least one browser that screws up when the query exceeds
a certain (and not very long) length.
One could argue that this browser is buggy and ought to be
fixed (and we did report it to the responsible party). But
it might not be reasonable to expect that indefinitely long
URLs will be properly supported by all HTTP implementations,
even though RFCs 1630 and 1738 do not give any length limits
for URIs or URLs. In other words, sooner or later the practice
of encoding long queries in the URL of a GET might break.
On the other hand, if the entire query is specified in the
URL of a GET, then we don't have to include the request
body of a method in the cache-matching key for such requests.
I'll admit that I can't think of a good answer to this dilemma.
-Jeff
Received on Friday, 5 January 1996 19:15:46 UTC