- From: Adrien de Croy <adrien@qbik.com>
- Date: Tue, 02 Jun 2009 14:40:28 +1200
- To: HTTP Working Group <ietf-http-wg@w3.org>
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