www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Russell <g.russ...@ieee.org>
Subject gateway ideas
Date Tue, 19 Dec 2000 03:18:40 GMT

>Be very careful with this - there are lots of things in HTTP/1.1 which
>deal with cache expiry which go to some lengths to ensure that it is
>clear how old files are and they are cached correctly. If arbitrary
>options are added to the proxy that break the spec it's unlikely to be
>accepted as a change.

I completely understand that this is an issue and I intend to be careful. 
Proxying in the traditional sense has strong specifications, they should be 
followed, and for good reasons. But gatewaying doesn't have such strong 
specifications, and they can be used in more flexable and application 
specific ways, which is what I want to do. We do have a common code base 
for gatewaying and proxying, and they do share quite a bit of 
functionality, but there applications are very different. All of the 
changes that I'm proposing are changes to the gateway functionality and 
shouldn't be used with a proxy. Maybe any gateway only modifications should 
be strictly bound to the proxypass configuration directive.

If I am wrong about gatewaying specs., or anything else, then please 
enlighten me. I've been wrong before and I expect to be again. The main 
spec. that I refer to is rfc 2616 <ftp://ftp.isi.edu/in-notes/rfc2616.txt>, 
and I know of no seperate proxy or gateway specs.

> > A driving factor behind most of my modification ideas are to create a
> > cacheing gateway that will increase the reliability of a completely
> > unstable site. Ideally, my completely dynamic website could go down for
> > several seconds, which it does all the time, and the cache would handle
> > most of the requests over that time.
>This kind of thing could probably have specific modes of behavior - in
>this case "offline mode" (needs a better definition, but I'm tired)
>where the should the backend be queried and the request fails or takes
>longer than a certain amount of time (5 seconds, whatever), cached data
>is returned in the meantime.

The idea should be a bit more simple. I could be something like "consider 
the expired cached file deleted unless you can't actually get a new one"

Thank you
Gabriel Russell

View raw message