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

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Monday, 17 August 1998 10:21:38 UTC