- From: Drazen Kacar <dave@public.srce.hr>
- Date: Thu, 17 Apr 1997 01:15:14 +0200
- To: http-wg@cuckoo.hpl.hp.com
Jeffrey Mogul wrote:
> The "public" directive was intended for a different purpose. From
> RFC2068:
>
> public
> Indicates that the response is cachable by any cache, even if it
> would normally be non-cachable or cachable only within a
> non-shared cache. (See also Authorization, section 14.8, for
> additional details.)
>
> While simply adding "Cache-control: public" to a response does
> imply that it is cachable, this doesn't say enough. I.e., how
> long is the response "fresh"? It seems more useful, in general,
> to use
> Cache-control: max-age=3600
> (or whatever), since this also implies cachability, but it also
> gives more explicit information to the cache.
What if freshness is infinite? I have a CGI which converts from X-Face mail
header format to XBM. If it receives If-Modified-Since it always returns
304. Anything it sends is cacheable and always fresh since it's a converter.
I wanted it to receive input via PATH_INFO (so it won't look like a CGI),
but I've found out that my servers have problems with that, since the input
can be quite large. So the URL has `?' in it and CGI returns
"Cache-Control: public" and Last-Modified with some fixed date in the past.
It should be good enough to make output cacheable.
--
.-. .-. Life is a sexually transmitted disease.
(_ \ / _)
| dave@srce.hr
| dave@fly.cc.fer.hr
Received on Wednesday, 16 April 1997 23:51:25 UTC