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

> 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.

	<mike

Received on Friday, 27 September 1996 12:25:43 UTC