Re: good practice for clients

>I was just trying to get my head around what exactly constitutes good
>practice on the part of proxy HTTP clients.  See what you make of
>this...

For those who don't follow uk newsgroups, this comes after some heated
discussion, where I was trying to encourage users of caches to accept
the fact that they were at least partly to blame in the case where
their WWW access was interrupted by their browser's inability to
degrade gracefully in the light of a proxy failure.

>Proxy HTTP clients, e.g. in WWW browsers and proxy servers which have
>been chained to other proxy servers, should allow for:
>
>  . direct connections to be used in the event of the proxy or
>      proxies failing

Going direct could simply be another `proxy' to add to the list.

Ideally, unless configured otherwise, clients should be monitoring the
responsiveness they see from each of the proxies that they have
available. If going direct is quicker than using the proxy then they
should go direct.

Of course, there are reasons why you would never want to go direct.
However, if your use of a proxy is merely to improve performance, why
not?

>  . multiple proxy servers to be used (in whatever configuration),
>      so that clients aren't wholly dependent on a single proxy

There needs to be a distinction drawn here.

Clients need to be able to handle both cases, where there are a number
of tightly coupled machines (a cluster) acting as a single proxy, and a
number of alternative proxies.

>  . proxying to be disabled for selected requests, e.g. based on
>      the domain name component of the request if present

I guess this is `no proxy' as it stands, although you might want to
extend this so that a client doesn't make use of a proxy in the case
where the resource is expected not to be cachable, (again depends on
your reasons for using a proxy). How this knowledge of cachability is
built up is another question ... past experience?

>  [ + detect and act appropriately when servers have multiple IP
>      addresses ?  Problems with DNS resolver code here ? ]

I don't know why this is in brackets. What's stopping resilient clients
being written now (other than nscd of course), what problems do you
anticipate in the DNS resolver code?

>Does the above sound reasonable as a baseline ?  I realise that this
>stuff isn't universally supported, but that's another story!
>
>Martin

I find it unbelievable that it isn't universally supported.

Neil.

Received on Monday, 17 June 1996 11:29:01 UTC