RE: Submission of HTTP Extension Framework (Mandatory)

From: Yaron Goland (
Date: Mon, Aug 17 1998

Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792392@RED-MSG-59>
From: Yaron Goland <>
To: "'Henrik Frystyk Nielsen'" <>, "''" <>
Date: Mon, 17 Aug 1998 12:51:37 -0700
Subject: RE: Submission of HTTP Extension Framework (Mandatory)

I think we have the beginning of a compromise here. 

I certainly don't want this "solution" to have to stick around for one
second longer than absolutely necessary. How about language along the lines
of "If you are communicating over a 1.1 end to end connection then you MUST
use the stuff Henrik specifies, if, however you are communicating over a 1.0
connection you either MUST reject the method or you MUST use the hacky
nightmare Yaron specified." The idea is that you don't have to support the
1.0 hack to be compliant with Mandatory but if you do decide to work over
1.0 then you MUST work as I specified.

Sound reasonable?


> -----Original Message-----
> From: Henrik Frystyk Nielsen []
> Sent: Monday, August 17, 1998 7:21 AM
> To: Yaron Goland; ''
> 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.