- From: Daniel W. Connolly <connolly@beach.w3.org>
- Date: Sun, 04 Feb 1996 15:52:29 -0500
- To: "David W. Morris" <dwm@shell.portal.com>
- Cc: html working group <html-wg@w3.org>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In message <Pine.SUN.3.90.960201175844.26919D-100000@jobe.shell.portal.com>, "D avid W. Morris" writes: > > >On Thu, 1 Feb 1996, Larry Masinter wrote: > >> > Was the character encoding problem, ever resolved with respect to i18n >> Any other forms should be handled with "FORM METHOD=POST >> ENCTYPE=multipart/form-data" as that encoding allows charset tagging >> of the values. > >The fundamental problem with this proposal is that it changes the >accepted semantics for POST vs. GET. Yikes! You're right. Larry: please don't recommend that folks use POST for query operations, nor use GET for operations with non-trivial side effects. 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?) We might look at this as a simple software defect, and expect the servers to get fixed. On the other hand, mandating support for arbitrarily long request lines in HTTP opens servers up to denial of service attacks and interferes with lots of handy performance optimizations. 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: GETQ /search? HTTP/1.x Content-Type: application/x-www-form-urlencoded search=a+b+c&stuff=xyz Dan
Received on Sunday, 4 February 1996 12:56:07 UTC