- From: David W. Morris <dwm@shell.portal.com>
- Date: Sun, 4 Feb 1996 17:47:03 -0800 (PST)
- To: html working group <html-wg@w3.org>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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