W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 8 Jul 2021 11:49:14 +1000
Cc: ietf-http-wg@w3.org
Message-Id: <01D0ADF1-19E3-4ECD-A86F-B771F4B7EAFF@mnot.net>
To: "Julian F. Reschke" <julian.reschke@gmx.de>
On 7 Jul 2021, at 7:03 pm, Julian Reschke <julian.reschke@gmx.de> 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.
> 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.

No, I don't want to change it. I don't see how it breaks anything, though.

IMO that absolute URIs in the start-line don't really help (and probably hurt) interoperability or security beyond that use case -- URNs failed to take off (thankfully), so the only practical use case for them is proxies effectively acting as gateways to non-HTTP protocols. I know that in theory HTTP supports other schemes, but in practice it doesn't (outside of that use case).

If we want to preserve this unused* capability in the protocol, we'll need to modify Semantics to do a check on the connection properties -- see proposed text at:


* If someone wants to assert otherwise, please refer to an even moderately used server implementation that supports serving non-HTTP URIs over HTTP as an origin server.

Mark Nottingham   https://www.mnot.net/
Received on Thursday, 8 July 2021 01:51:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 8 July 2021 01:51:53 UTC