W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: Issues-list item "CACHING-CGI"

From: Drazen Kacar <dave@public.srce.hr>
Date: Thu, 17 Apr 1997 01:15:14 +0200
Message-Id: <19970417011514.39166@jagor.srce.hr>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:34 EDT