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

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

> David Morris wrote:
>> 
>> 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.
> OK, so we send back a 401, with WWW-Authenticate
>
> But then what does the client do if it thought it was talking to a proxy?  I 
> guess there's no problem, since auth will work through a proxy already...
>
> So IOW the handling of the request is based on the proxy / servers knowledge 
> of which sites it's an O-S for.
>
>> 
>> It must be able to recognize local content and it's own host name.
> understood.
>
> What about the case where a proxy offers authenticated proxy services over 
> the internet but is also an origin server.  If a request to an origin server 
> can contain an absolute URI then the proxy can no longer tell whether it's 
> being asked to be a proxy for that domain, or be a server for that domain. 
> If it does host the domain, then it can assume it's being an origin server 
> without problem, but what if it doesn't host it?  Should it then presume it's 
> being asked to be a proxy?

Obviously.

>
> if it sends back a 407 (which could be reasonable), then a UA may choke on 
> that if it thought it was making a request to an origin server.

Doesn't much matter because something is seriously wrong if the client 
thinks it is talking to an origin server and the server it connects 
directly to as the origin for x.mydomain.com, presumably because the DNS 
the client is configure to resolve names with pointed at this server. 
Clients are already a bit weak in general in the decision process related 
to whether a host name is local and shouldn't proxy or is remote and 
should proxy so in this case we have a poorly configured DNS and/or client 
proxy selection script, etc. And we either get a 407 from the proxy which 
is an early clue to whomever the user gets tech support from, or they get
some other 4xx or 5xx error related to the server not existing.

>
> I guess this isn't a big issue... but if relative URI requests die out, then 
> this could become bigger.  Which makes me wonder, why after over 10 years of 
> RFC2616 doesn't any UA send absoluteURI in requests except when configured to 
> talk to a proxy?

My guess would be that this condition exists because the host: header / 
non-proxy URI form is known to work.

Received on Tuesday, 2 June 2009 04:38:25 UTC