Re: [art] Question regarding RFC 8089

["Roy T. Fielding" <[e-mail]>]

> On Jan 18, 2019, at 11:52 AM, Larry Masinter <[e-mail]> wrote:
> 
> This bit that HTTP can be used by a proxy to resolve any URLs, not just http: and https: ones, is weakly supported by a passing MAY.
> There isn't sufficient evidence of independent interoperable implementations (based on specification) for such a major extension to the "range of the HTTP dereference function".

Hi Larry,

We deployed this in 1994.

   http://1997.webhistory.org/www.lists/www-talk.1994q1/0549.html

It is still implemented in many current proxying clients.

> Yes, theoretically, something like this COULD be specified without breaking HTTP,

It has been specified in HTTP/1.x since 1995.

> but that's different from saying that scheme registrations can't restrict the use of fragment identifiers with URLs of that scheme.    I think that if you want to allow fragments in URLs of a given scheme, the scheme definition should define how it should be treated by fetch, and if such use requires generation of "some metadata document", how those metadata documents work with fragment identifiers should be defined (by their MIME type's registration, I suppose).

It is not a question of "want" or "should be treated", nor even a question of whether
or not is is a good idea.  It is a fact.  That's how HTTP was designed to work.

> So I'd say no, you can't use a fragment identifier with a "mailto:" URL. Or a "sip:" one. But ok with "data:", and even "ftp" and "file".

I can. I still remember implementing it in libwww-perl.

....Roy