Re: Issues-list item "CACHING-CGI"
Drazen Kacar (dave@public.srce.hr)
Thu, 17 Apr 1997 01:15:14 +0200
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