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

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.

Received on Tuesday, 2 June 2009 02:22:21 UTC