Re: draft-holtman-http-safe-00.txt

gtn@ebt.com (Gavin Nicol) wrote:
>>headers?  Are there *any* headers or procedures which can't be made to treat
>>a POST with "Safe: yes" as, in effect, a GETwithBodyInsteadOfSearchpart?
>
>This is not the real issue. [...]

	Well..  As it is people are so on edge from the recent spate
of holier, wiser, greater and busier than thou put downs that we're
quibbling over individual words instead of communicating (very bad
for someone as typo prone as I :).  Let's not take it to the point
of reading each others' minds about what issues are knocking around
in them. :) :)


>As you can see, it's mostly semantics. One emphasises the data
>retrieved, the other, the data sent.

	Yes, there's that difference in semantics, but once you add
a body to GET which will be sent to the server, the clarity of that
difference is gone (you *are* POSTing content, even though it may
result only in retrieval, as many POSTs presently do as well).  That
perhaps was behind the QUERY suggestion, though it's too specific.
The FORM may be using POST instead of GET because the subordinate
content (body) will include "private" or "secure" information which
is "safe" but shouldn't be "visible" in the ?searchpart of a URL,
and no search will be done.

	The key difference, I agree, is that a GET by convention must
be safe, so you don't need a reply header to know that.  What you're
trading for that, if you add a body, but not also expand the http URL
specs, is ability to specify the resource completely in any context,
i.e., independently of HTML markup (that's what ?searchpart is doing
for you).  If you don't want to lose that for *all* methods (and only
GET has it at present), you will have to specify two components in the
URL, the Request-URI and particular subordinate content(s), which are
likely to be in different locations, and may involve privacy and security
considerations, beyond safety, per se.  I don't see the need for that
complication which a GETwithBodyInsteadOfSearchpart would create, and
not just for POST with Safe: yes, unless there's something in those 8
thousand lines of the HTTP/1.1 draft that's wanted and can't be had
with the latter.

	There may be something that's wanted and can't otherwise be had,
but what, beyond perceptions of semantics?  ('Cuz a "GET with body to
POST safely" feels a bit twisted to me. :) :) :)

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Thursday, 10 October 1996 14:22:30 UTC