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

On Tue, 2 Jun 2009, Adrien de Croy wrote:

>
> 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.

Yes it is ... in this example, it would see the request as local content 
since it was recognized as such and perform WWW-Authenticate, nothing else
would be sensible.

It must be able to recognize local content and it's own host name.


>
> 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:56:30 UTC