PHWinfo - Afficher un message - Getting Allow from credentials from a header.

16/03/2005, 15h59

Andy Davidson <$andy$@nosignal.org> writes:
> [Chris Morris wrote in comp.infosystems.www.servers.unix]
> > It (in Apache 1, at least - I didn't look at the Apache 2 version) is
> > a very large hack, so there may be side-effects, but we managed to run
> > it in production for several months without serious problems. There
> > were other authentication-related issues, but provided you *only*
> > proxy and don't cache too, they won't bite you.
>
> Thanks for your incredibly quick reply.
>
> Cacheing is in the wishlist of good things to have the proxies doing -
> if we can limit the number of requests as well as balance requests, then
> this is perfect, but I will certainly take a look.
>
> Do you remember what you saw with cacheing ?

General issues:

Make sure you send the appropriate no-cache or private-cache-only
headers with any page that requires authentication. This should happen
automatically with Basic authentication, but in our case we had a set
of pages where either using Basic auth or coming from a particular IP
block was sufficient to authenticate - and those needed explicitly
setting to only private caching.

Depending on how aggressively you cache, you may need to let your
local web developers know about the force-reload command in their
browser.

mod_rpaf sometimes gave bad entries in the hostname if there was a
keepalive connection. I *think* this only happened when we put two
reverse proxies in series, but I could be wrong. This was a while ago
and I can't remember the details.

Make sure all your Last-Modified, Expires, etc headers are in GMT
timezone.

Obviously, if you're using multiple back-end machines, make sure that
they're always synchronised or the reverse proxy might end up
assembling a page from a range of components. This is more likely if
you're using caching.

Apache mod_proxy specific issues:

If you use apache's mod_proxy, you might want to experiment with other
cache cleanup routines. We found that fastrm (from the NNTP daemon) on
any cache file with an access time more than N hours ago was more
effective than mod_proxy's own cache cleanup routines. YMMV there.

There at least was a bug in Apache mod_proxy that corrupted the cache
copy if the original response had a header line longer than 4096
bytes. Never caused a problem in practice for us but I don't know what
you put in the headers on your system.

--
Chris

16/03/2005, 15h59	#4
Chris Morris Messages: n/a Hébergeur:	Re: Getting Allow from credentials from a header. Andy Davidson <$andy$@nosignal.org> writes: > [Chris Morris wrote in comp.infosystems.www.servers.unix] > > It (in Apache 1, at least - I didn't look at the Apache 2 version) is > > a very large hack, so there may be side-effects, but we managed to run > > it in production for several months without serious problems. There > > were other authentication-related issues, but provided you only > > proxy and don't cache too, they won't bite you. > > Thanks for your incredibly quick reply. > > Cacheing is in the wishlist of good things to have the proxies doing - > if we can limit the number of requests as well as balance requests, then > this is perfect, but I will certainly take a look. > > Do you remember what you saw with cacheing ? General issues: Make sure you send the appropriate no-cache or private-cache-only headers with any page that requires authentication. This should happen automatically with Basic authentication, but in our case we had a set of pages where either using Basic auth or coming from a particular IP block was sufficient to authenticate - and those needed explicitly setting to only private caching. Depending on how aggressively you cache, you may need to let your local web developers know about the force-reload command in their browser. mod_rpaf sometimes gave bad entries in the hostname if there was a keepalive connection. I think this only happened when we put two reverse proxies in series, but I could be wrong. This was a while ago and I can't remember the details. Make sure all your Last-Modified, Expires, etc headers are in GMT timezone. Obviously, if you're using multiple back-end machines, make sure that they're always synchronised or the reverse proxy might end up assembling a page from a range of components. This is more likely if you're using caching. Apache mod_proxy specific issues: If you use apache's mod_proxy, you might want to experiment with other cache cleanup routines. We found that fastrm (from the NNTP daemon) on any cache file with an access time more than N hours ago was more effective than mod_proxy's own cache cleanup routines. YMMV there. There at least was a bug in Apache mod_proxy that corrupted the cache copy if the original response had a header line longer than 4096 bytes. Never caused a problem in practice for us but I don't know what you put in the headers on your system. -- Chris