- From: David Morris <dwm@xpasc.com>
- Date: Mon, 1 Jun 2009 19:55:50 -0700 (PDT)
- To: Adrien de Croy <adrien@qbik.com>
- cc: HTTP Working Group <ietf-http-wg@w3.org>
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