httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: [PATCH] error responses have wrong headers (part 2)
Date Sat, 10 May 1997 01:54:20 GMT
>> No, we don't, because Cache-Control: private is not the right thing
>> to send even if r->no_cache is set.  r->no_cache was a temporary hack
>> that is obsoleted by Vary.  In order to be HTTP/1.1 compliant, such a
>> module MUST output a correct Vary header field; if it doesn't want to
>> be HTTP/1.1 compliant, then the Expires field is sufficient.
>No, wait... r->no_cache has always had the implied meaning of "don't
>let proxies cache this, because it's only for the browser that made
>the request." It is true with HTTP/1.1, mod_neg can use Vary: instead,
>to do what it needs to; and it does. And I agree that in most cases,
>an appropriate Vary header would be the thing to do.
>However, there are other instances where r->no_cache might be set, and
>where Cache-Control: private would be the appropriate response. And
>the current code would seem to me to be the correct thing for the
>server to do.

r->no_cache has never meant "don't let proxies cache this"; it means
don't give this content to other user agents with different request
profiles.  It is the reason why Vary exists.  The after-patch code is
still sending

   Expires: <same as Date>

which means the same thing under both HTTP/1.0 and HTTP/1.1 in terms
of preventing a shared cache from reusing a response -- it forces the
cache to do a conditional GET containing the new UA profile.  There
is not, and has never been, any reason to add Cache-Control in that
situation, and since I am the person who wrote that bit of code I am
absolutely sure that it isn't needed for anything else.


View raw message