Re: Benjamin Kaduk's Discuss on draft-ietf-httpbis-messaging-16: (with DISCUSS and COMMENT)

On Wed, Jul 07, 2021 at 11:03:14AM +0200, Julian Reschke wrote:
> Am 02.07.2021 um 10:09 schrieb Mark Nottingham:
> > ... > The decisions about absolute-form requests were made *way* back when.
> My reading of the archive (circa September and October 1995 -- I'm sure
> those that were there will correct me) is that Host headers were added
> to address the multiple-hosts-on-an-IP problem in a way that was
> backwards-compatible with HTTP/1.0, but because some folks wanted to
> enable the use of URNs, proxies were required to support and use the
> absolute form, so that URNs could be (theoretically) resolvable through
> them. That didn't happen, but it is possible to use e.g., FTP through a
> HTTP proxy as a result (last I looked).
> > 
> > I think the solution here is to restrict the statement above so that it only applies to proxies, and to add a requirement for origin servers (including gateways) to specifically check absolute-form URIs for alignment regarding the scheme.
> > 
> > Does that make sense to everyone (especially Roy, who has the most history here)?
> > ...
> 
> Not really.
> 
> My understanding is that support for "absolute-form" in request lines
> has been a "MUST" level requirement for ages.

Yes, for me it appeared in RFC2068 as a MUST already.

> Do you want to change that? If not, we'll still have to define how to
> compute the target URI from the request line, so special-casing the
> support for proxies breaks that.

Also, let's keep in mind that proxies can suddenly become servers when
they intercept some well-known URIs (internal management ones, etc).
Let's not start to special-case anything. And gateways are commonly
placed in front of proxies, having to deal with their absoluteURI
format as well.

Speaking about the ability to reconstruct the absolute URI, from within
a server there will always be some ambiguity left depending on the
knowledge about the connection: some tunnels that offload TLS can be
installed in front of them without touching any header field, and the
server doesn't see a secure connection in this case. If the port is
dedicated that may be OK, if it's not, after all, as long as the
authority remains the same... that's basically the same place :-/

And the announced port is not a discriminant. One interesting trick to
play with that I came across a week ago was to direct my browser to
http://127.0.0.1:443/ and https://127.0.0.1:80/. In such cases the
port is explicitly present in the Host field since it doesn't match
the scheme used, but if this passes through an SSL offloader the info
is definitely lost.

In short there has always been some ambiguity in that area and I don't
see how it could be addressed 24 years after RFC2068 has settled
everything in stone anyway.

Just my two cents,
Willy

Received on Wednesday, 7 July 2021 14:52:18 UTC