Re: [art] Question regarding RFC 8089

FWIW, the EMWAC (Edinburgh Uni) web server implemented proxying of non-HTTP URIs 
back in about 1998.  I recall this capability being used by a company I worked 
for to implement content scanning of material accessed from FTP servers.

Generally, I think it was quite common back then to put ftp:... into a browser 
bar and have that retrieved via HTTP and a proxy server.

#g
--

On 18/01/2019 22:29, Roy T. Fielding wrote:
>> On Jan 18, 2019, at 11:52 AM, Larry Masinter <LMM@acm.org> 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
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>