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

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

From: Mike Meyer <mwm@contessa.phone.net>
Date: Tue, 24 Sep 1996 20:37:56 PST
Message-Id: <19960924.7874FF8.12CF8@contessa.phone.net>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1622
> As I believe Jeffry Mogul has already presented, it would break the
> assumptions of some very important caches if they can't assume idempotence
> of GET.

This is true. On the other hand, the functionality is sufficiently
important that I routinely build applications that do non-idempotent
GETs when I'm building for a captive audience.

rom what I can tell, the easiest way to provide this functionality is
by providing a mechanism for a response to say whether or not the
request that it is in response to is idempotent or not. Possibly
extensions to HTML - adding a METHOD attribute to the A tag, and
allowing FORM elements in the tag - would do the trick. However, that
feels like a kludge to me.

If everything involved is HTTP/1.1, then there isn't a problem. The
transition period could well be interesting, but that's not unusual
when providing new functionality to an old mechanism. Other

Since this feature only applies to the RESPONSE, the person generating
the response has the responsibility (sorry) for making sure that the
caches/clients in the chain are all HTTP/1.1, just like they now have
the responsibility to make sure that the GET is idempotent (or that it
not being idempotent won't break things for any users). I've not given
the proxy/caching in 1.1 to know whether the above constraint is
necessary, but it should certainly be sufficient.

Received on Tuesday, 24 September 1996 20:49:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:20 UTC