RE: Submission of HTTP Extension Framework (Mandatory)

From: Henrik Frystyk Nielsen (
Date: Mon, Aug 17 1998

Message-Id: <>
Date: Mon, 17 Aug 1998 10:21:29 -0400
To: Yaron Goland <>, "''" <>
From: Henrik Frystyk Nielsen <>
Subject: RE: Submission of HTTP Extension Framework (Mandatory)

At 22:00 8/11/98 -0700, Yaron Goland wrote:
>Regarding the 102 vs header. My situation is this: If I can't use mandatory
>through 1.0 proxies then I can't use mandatory. Which would suck. So lets
>have ourselves a compromise. If you use 102 then you are done, you had done
>your duty, everything is cool. However, If you decide to use a header
>instead (we will support both in the spec) then you MUST include both
>pragma: No-Cache and Cache-Control: No-Cache on the response. You MUST use a
>header any time a 1.0 proxy or client is involved. This sucks but it is
>better then rendering mandatory useless for the next five years or so. I
>think this is better than the ACK idea because ACK means that all such
>requests are uncacheable forever.

If we can make this a non-normative part of the spec then it would be a
work around solution has a chance of dying out along with HTTP/1.0 proxies.

>BTW I think Roy is right regarding OPTIONS as the real solution. The only
>problem is that an annoying number of people still don't want to pay that
>single round trip price. Which I think is a nonsence argument because if you
>are using a mandatory extension you are already in weirdoville anyway. What
>we really need are some common rules for how to cache information you get
>back from an OPTIONS call. 
>BTW, an edge case that still is worth thinking about is what happens if you
>do an OPTIONS, a server claims support and then two or three days later you
>still assume support is there but the server crashed and was brought back up
>with an older version that doesn't support your extension any longer? Major
>major ick.

It is not an edge case - it is the difference between metadata and
transaction data. OPTIONS is a solution for the former, Mandatory for the

Henrik Frystyk Nielsen,
World Wide Web Consortium