Re: absolute URI in request to origin servers which are also proxies.

I think you'll find there are a lot of proxy products which also act as 
origin servers for whatever reason.  Admin sites, or even reverse 
proxying are common examples of this.

There were semantic differences in HTTP/1.0 between "proxy" and "server" 
requests - e.g. those which contained an absoluteURI or not.

This distinction was removed in 1.1, by requiring origin servers to 
accept absoluteURI in a request.

however the distinction is still required in cases such as auth.  
Configuration doesn't make any difference for this.  the proxy / server 
can no longer tell what the appropriate response should be.

Take a simple example.  Proxy at A is also a server for www.example.com, 
but requires authentication for access to that site and also requires 
proxy users to auth.  Proxy A receives a request from a client on the 
internal network for

GET http://www.example.com HTTP/1.1
Host: www.example.com
etc

Should the proxy send back  a 407 or a 401?  should it send 
Proxy-Authenticate or WWW-Authenticate?

How should it tell what to do?

This isn't a configuration issue.

Adrien

David Morris wrote:
>
> On Tue, 2 Jun 2009, Adrien de Croy wrote:
>
>> There is an ambiguity brought about by the requirements of RFC2616 to 
>> require origin servers to support absolute URI in requests (RFC2616 s 
>> 19.6.1.1).
>>
>> If you consider the case of a proxy which is also an origin server, 
>> then you get a problem when the proxy receives a request for a URI 
>> for which the proxy is an origin server, and that request contains an 
>> absolute URI, and the proxy requires the client to be authenticated.
>>
>> In such cases, it's impossible to tell whether to send a 
>> Proxy-Authenticate, or a WWW-Authenticate header in the response, 
>> since you can't tell from the syntax of the request whether the 
>> client believes it is talking to a proxy or an origin server.
>
> Huh ... a proxy which can't differentiate based on local configuration 
> whether content is local or proxied is fundamentally flawed and I 
> suspect has the potential for security issues. The shape of the URL 
> should not influence how the server differentiates handling.
>
>> I've never seen a client send an absoluteURI in a request to an 
>> origin server, so the obvious solution is to ignore RFC 19.6.1.1, and 
>> base the decision on the semantics of the request.
>
> NO ... the decision must be made based on the configuration of the 
> proxy software.  Having the client able to influence the choice makes 
> no sense.
>
>> However that doesn't seem like a great option if clients are one day 
>> going to start send requests to origin servers with absolute URIs.
>>
>> Should this requirement be deprecated?  Otherwise how should this 
>> case be handled?  A proxy that can also be an origin server needs to 
>> know
>
> It doesn't need to know what the client believes. I frankly think it 
> foolish to combine the functions in a single software installation, But
> the combined server needs external configuration to know what it is 
> willing to do for the client.
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 2 June 2009 02:37:42 UTC