- From: Gavin Nicol <gtn@ebt.com>
- Date: Thu, 25 Jan 1996 08:33:54 -0500
- To: masinter@parc.xerox.com
- Cc: nms@nns.ru, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>a) multipart/form-data, not forms-data
I stand corrected.
>b) there is no body in a GET method, and no reason to add one;
Well, my reading of an admittedly somewhat old HTTP spec gives me
this:
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 messages
| Full-Response
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.4
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
Simple-Request = "GET" SP Request-URI CRLF
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
Which does not seem to me to disallow a GET method from having a body,
except as a "Simple-Request". If the get method is sent as a "Full
Request", it can take a body. Most current servers do not support
this, but if they can support POST, they should be able to support
GET, indeed, we loose very little if we remove the "Simple-Request"
clause from the above.
Also, there is a reason to add one; For certain types of applications,
it makes very good sense to send additional data with a GET, and
unless we allow Entity-Bodies, there is no reliable way of sending
additional information that uses anything other than ASCII. It is, of
course, possible to achieve much the same thing bu overloading the
semantics of POST, but that makes as much sense to me as calling
read(), write().
>There's no quality factor for accept-encoding either. For me, it works
>best to think of 'charset' as a special kind of encoding, namely, one
>that is used to encode sequence-of-character, while other kinds of
>encodings are used to encode sequence-of-octet.
Hmm. It seems to me that allowing content negotiation for all fields
makes more sense.
Received on Thursday, 25 January 1996 05:37:54 UTC