W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

RE: Protection spaces and proxy servers

From: Josh Cohen <joshco@microsoft.com>
Date: Thu, 7 May 1998 12:54:25 -0700
Message-Id: <8B57882C41A0D1118F7100805F9F68B502D2CBD2@red-msg-45.dns.microsoft.com>
To: "'Dominic.Chambers@mimesweeper.com'" <Dominic.Chambers@mimesweeper.com>, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/109

> -----Original Message-----
> From: Dominic.Chambers@mimesweeper.com
> [mailto:Dominic.Chambers@mimesweeper.com]
> Sent: Tuesday, May 05, 1998 4:40 AM
> To: http-wg@cuckoo.hpl.hp.com
> Subject: Protection spaces and proxy servers
>      Query?
>      ------
>      What is the protection space for a proxy server which forces 
>      authentication? Does the "..canonical root URL of the 
> server being 
>      accessed.." refer to the proxie servers URL, or the 
> origin servers 
>      URL. The later would imply that the client should stop 
> sending proxy 
>      authorization headers whenever the protection space of 
> the origin 
>      server changes, even though the proxy has not changed.
>      If proxy servers request authorization, it is likely 
> that the same 
>      authorization will be required for all/most resources 
> accessed through 
>      the proxy, and I must suppose that the protection space 
> refers to the 
>      proxies URL, and therefore all requests a client makes 
> via that proxy 
>      must require authorization as long as the realm remains 
> constant. Is 
>      this the case?
I beleive this is correct.  There are some complicated cases
where this definition may fail to be true when cascaded proxies
are used.  Ideally, each proxy in a chain can use a different realm,
but to the client it would appear as two different realms on
the same proxy since the client doesn't necessarily see the higher
level proxies.

Josh Cohen <josh@microsoft.com>
Program Manager IE - Networking Protocols 
Received on Thursday, 7 May 1998 12:56:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC