httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: proxying
Date Thu, 25 Jan 1996 05:09:47 GMT
On Wed, 24 Jan 1996, Paul Richards wrote:
> Well, I guess I should go read some more docs but I though Expires was
> advisory not mandatory, advisory timeouts are pointless. If Expires
> is only advisory then you can never be sure that people are seeing
> your updated pages and not some stale copy from a cache.

Well, I suppose DNS refresh times are voluntary as well.  According to 
the HTTP/1.0 specification [1], "Applications must not cache this entity 
beyond the date given."  Did you need something more explicit?  :)

> > > It really concerns me 
> > > that there's no way to prevent incorrect (i.e. stale) data from being 
> > > served from caches. 
> > 
> > Not true.  If you are paranoid about stale copies, use Proxy: no-cache.  

Alexei did correct me, it's Pragma: no-cache, my mistake.

> I'm not paranoid about stale copies to the point that I don't want my
> pages cached, I just want to be sure that, with no further effort on
> my part, my updated pages will appear everywhere after a time period X.

Then we hack Apache to have a mode which sends Expires: headers which are 
always time X ahead of the current time.  

> > be configurable.  The AOL caches, for example, always send IMS requests 
> > for HTML documents, but cache GIF images for up to 6 hours (unless they 
> > have a Proxy: no-cache).  
> You're kind of making my point. There needs to be an "enforced
> standard" to deal with the whole caching issue.

This is for documents which don't send Expires:, only Last-Modified.
Well, I won't speak authoritatively to that, but if it *is* keeping stuff 
past an Expires: time, then it's in violation of the protocol.  

> Circumventing caching mechanisms just so you can bump up your hits is
> not a good trend to set. 

It's a subtle thing now, unfortunately.  If you ask the kind of companies 
we deal with "make a choice - a reduced hit count, or double your page 
download time", they will choose the former.  We're working to counter 
that, with mixed results.  Many companies ask "well, what will improve 
things without sacrificing hit counts?  Mirror sites in the UK?  Fatter 
pipe to the backbone?" etc.  

> I think requiring proxy servers to return stats is just silly. I think
> there's a bit of an obsession with hit counts.  About the only valid use
> I can see for them is in determining that your server's very busy. If
> my server was very busy I'd be wanting to offload to caches. All other
> reasons for collecting hit counts are bogus because they mean absolutely
> nothing in terms of users or whatever.

Well, we come from different worlds.  

Consider - when advertising-supported content sites start moving towards
micro-payment based content (where you pay a penny, or a fraction of a penny,
for an article or object), where does caching fit in?  If you can build a
network of trust where the caches are acting as "resellers" of your content,
we all win.  But it is a long road to get there, and the proxy cache 
arena needs to solidify its methods to build that trust.  


[1] <URL:>

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--  http://www.[hyperreal,organic].com/

View raw message