Subject: Re: Clarification on use of Content-Location header

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Jul 2010 16:12:10 +1000

Since we're going on this tangent -

Is this (proxying other URI schemes through HTTP) worth making a little more explicit? The question of whether non-HTTP URI schemes are allowed in HTTP comes up from time to time. Other issues (e.g., what to do with the Host header) come up as well.

Cheers,

On 15/05/2010, at 7:34 AM, Roy T. Fielding wrote:

> On May 14, 2010, at 1:09 PM, Henrik Nordström wrote:
> 
>> fre 2010-05-14 klockan 12:36 -0700 skrev Roy T. Fielding:
>> 
>>> All schemes are dereferenceable, including urn, info, and tag.
>> 
>> Are they?
> 
> Yes.  Any scheme can be proxied through HTTP, even when it
> might be unwise to do so.
> 
>> Quote from the tag scheme specification RFC4151:
>> 
>>       There is no authoritative resolution mechanism for tags.  Unlike
>>       most other URIs, tags can only be used as identifiers, and are
>>       not designed to support resolution.  If authoritative resolution
>>       is a desired feature, a different URI scheme should be used.
>> 
>> Some of the  URN name spaces have similar issues.
> 
> That doesn't prevent anyone from introducing a resolution, deploying
> it, and then configuring their web tools to dereference it.
> 
> There is a long history of URN-like specifications living in some
> fantasy land that has no correspondence with Web technology.
> 
> ....Roy
> 
> 

--
Mark Nottingham     http://www.mnot.net/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 14 Jul 2010 00:10:05 -0700

> Is this (proxying other URI schemes through HTTP) worth making a little more explicit? The question of whether non-HTTP URI schemes are allowed in HTTP comes up from time to time. Other issues (e.g…

We could add something to the discussion on URIs in p1
or maybe add a dedicated section in p2.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Jul 2010 17:13:20 +1000

I was thinking maybe a note in p1 request-target's description, as well as appropriate adjustments elsewhere in p1.

I've opened
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/218

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 14 Jul 2010 17:52:38 +0200 (CEST)

On Wed, 14 Jul 2010, Mark Nottingham wrote:

> Is this (proxying other URI schemes through HTTP) worth making a little more 
> explicit? The question of whether non-HTTP URI schemes are allowed in HTTP 
> comes up from time to time. Other issues (e.g., what to do with the Host 
> header) come up as well.

As author of a tool that sends all sorts of URIs over HTTP proxies, I must say 
that it would help to get the (lack of) documented support better detailed.

-- 

  / daniel.haxx.se

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 15 Jul 2010 17:21:46 +0200

Something along the lines of http proxies may act as gateways for non-http URIs such as ftp:// or gopher:// translating http operations on such URIs to appropriate actions in their respective protocol.  
----- Ursprungsmeddelande -----
> > Is this (proxying other URI schemes through HTTP) worth making a
> > little more   explicit? The question of whether non-HTTP URI schemes
> > are allowed in HTTP   comes up from time to time. Other issues (e.g.,
> > what to do with the Host   header) come up as well.
> 
> As author of a tool that sends all sorts of URIs over HTTP proxies, I
> must say   that it would help to get the (lack of) documented support
> better detailed.
> 
> -- 
> 
>     / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 16 Jul 2010 19:46:51 +0200 (CEST)

On Thu, 15 Jul 2010, Henrik Nordström wrote:

> Something along the lines of http proxies may act as gateways for non-http 
> URIs such as ftp:// or gopher:// translating http operations on such URIs to 
> appropriate actions in their respective protocol.

Yes. Ideally, it could also say something that proxies MAY deal with them and 
that if they decide to deal with them, they actually still speak HTTP even if 
the URL it passes on is another protocol.

In reality, it tends to mean that nothing but GET works, even if I've heard of 
HTTP proxies that actually support ftp upload using PUT!

-- 

  / daniel.haxx.se

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 16 Jul 2010 19:56:16 +0200

> HTTP proxies that actually support ftp upload using PUT!

Squid supports PUT (and DELETE) to ftp:// since 1998.

But unfortunately it seems all the major browsers have forgot that HTTP
PUT makes sense on ftp:// so it's not used much.. but at least one of
them did have support for this in some earlier versions.

Regards
Henrik