Re: non-HTTP URIs in HTTP requests

Erik,

basically, I think what matters most is whether the request method is  
defined for the geo: protocol.

I do not think that http forbids the use of non http URIs because the  
client component is supposed to select the correct connector based on  
the protocol. So, a geo: URI would normally never end up in an HTTP  
request.

OTH, HTTP 1.1 requires the Host header field and if that does not  
match the host of the URI you end up with a proxy request anyway. So  
the question would technically be how the target host of the first  
request hop (as given in the Host header) deals with the geo: URI. If  
you write a proxy to do some sort of resolution of the geo: URI I  
think that should work.

HTH,

Jan

On Jan 6, 2010, at 7:30 PM, Erik Wilde wrote:

> hello.
>
> i have a technical question about HTTP and URIs. my use case is that  
> i am considering to use HTTP for the resolution of non-HTTP URIs, so  
> that for example (this is my use case) a geo:37.0625,-95.677068 URI  
> could be "resolved" via HTTP. regardless of the actual process (what  
> "resolution" returns in the response), i am currently just trying to  
> find out whether it would be legal to send a HTTP request like this:
>
> GET geo:37.0625,-95.677068 HTTP/1.1
>
> it seems to me that RFC 2616 does not prohibit such a use, but i am  
> sure that a lot of people will dislike it for various reasons.  
> however, currently i am just interested to figure out whether it's  
> legal, and i think it is (not the geo: per se, which is not yet a  
> standard, but the fact that there is a non-HTTP URI in the request).  
> if i am mistaken, feedback would be greatly appreciated.
>
> thanks,
>
> erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
>       dret@berkeley.edu  -  http://dret.net/netdret
>       UC Berkeley - School of Information (ISchool)
>

--------------------------------------
Jan Algermissen

Mail: algermissen@acm.org
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

Received on Wednesday, 6 January 2010 20:29:41 UTC