W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: HTTP working group status & issues (please reply)

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Fri, 27 Sep 1996 17:34:00 -0500 (EST)
To: mwm@contessa.phone.net
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01I9ZBGVF9EM0089K5@SCI.WFBR.EDU>
mwm@contessa.phone.net (Mike Meyer) wrote:
>> Let me make this very clear.  You routinely build applications
>> which violate the definition of the HTTP protocol with regard to
>> the semantics of the GET method,
>
>Yes I do. I can't get the results I need without doing that.  Like so
>many HTML authors, I'm just doing what it takes to get the job done.
>I'm suggesting ways to get those results without abusing the protocol
>in what I believe is an appropriate forum.
>
>> And yes, this does include FORM-processing scripts which accept POST
>> information in the form of a GET+parameters.  Any significant action
>> other than retrieval requires a method other than GET, and the fact that
>> most HTML user agents do not allow you to specify the method in a
>> normal link does not modify the intentions of the protocol.
>
>Nor does it modify my needs. Are there user agents that support a
>METHOD attribute for the A element?
>
>> Whether or not a method is intended to be "safe" in that sense must
>> be determined by the client prior to the first usage of that method.
>
>Makes sense. It sounds like two things need to happen. 1) POST with
>parameters, and 2) putting a METHOD attribute on the A element. Older
>user agents will ignore the METHOD attribute and do a GET, at which
>point I can send back a response indicating that this operation is NOT
>idempotent, with a link to follow if you REALLY want to do it.
>
>> None of this, BTW, has anything to do with whether or not a previous
>> response may be reused (with or without contacting the origin), which
>> is completely covered by the Cache-Control header field.
>
>I don't think anyone thought it did.

	I'm not sure I follow everything that is being said here.  In
the case of an "Idempotent: yes" reply header from a POST, any caching
servers should ignore it, and instead just pay attention to the
Content-Location header.  Only the browser cares about it, in relation
to disposition of the content for the POST.  In the case of an
"Idempotent: no" reply header from a GET, the Cache-Control headers
regulate the caching servers, and again, only the browser takes
the Idempotent header into account, though you haven't spelled out
how.

	Some way to associate URLs with the POST METHOD beyond FORM
tags and of associating prior content with them using HTML would
be desireable, so that, for example, bookmark files need not go back
to client-specific hotlist designs, but do you have specific thoughts
on that?

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
Received on Friday, 27 September 1996 14:40:12 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:14 EDT