W3C home > Mailing lists > Public > uri@w3.org > January 2010

Re: non-HTTP URIs in HTTP requests

From: Ted Hardie <ted.ietf@gmail.com>
Date: Thu, 07 Jan 2010 12:42:11 -0500
Message-ID: <6e04e83a1001061120ybe05ecr95f9b115e39cc6cd@mail.gmail.com>
To: Erik Wilde <dret@berkeley.edu>
Cc: "uri@w3.org" <uri@w3.org>
Hi Erik,

This would probably be better sent to an HTTP-specific
list (e.g. HTTPBIS, at ietf-http-wg@w3.org).

My personal take is that this permitted from a protocol perspective
but requires server which understands this form of a request URI.
The text from section 9.3 of 2616 is:

"9.3 GET

The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI. If the Request-URI refers to
a data-producing process, it is the produced data which shall be
returned as the entity in the response and not the source text of the
process, unless that text happens to be the output of the process.

The semantics of the GET method change to a "conditional GET" if the
request message includes an If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range header field. A conditional GET
method requests that the entity be transferred only under the
circumstances described by the conditional header field(s). The
conditional GET method is intended to reduce unnecessary network usage
by allowing cached entities to be refreshed without requiring multiple
requests or transferring data already held by the client.

The semantics of the GET method change to a "partial GET" if the
request message includes a Range header field. A partial GET requests
that only part of the entity be transferred, as described in section
14.35. The partial GET method is intended to reduce unnecessary
network usage by allowing partially-retrieved entities to be completed
without transferring data already held by the client.

The response to a GET request is cacheable if and only if it meets the
requirements for HTTP caching described in section 13.

See section 15.1.3 for security considerations when used for forms. "

To make this useful for geo as a request-uri, you'd need something
that defines what is returned.  The geopriv document specifying
geo URIs (draft-ietf--geopriv-geo-uri) has some examples in Section
6, but they don't really specify what an HTTP GET on that resource
would return; instead they presume some browser-side logic
that would offer choices of what to do.  Those might result in,
say, a point-of-interest query with the geo uri's location data as a parameter.
But the result of what you want doesn't seem to me to be specified



On Wed, Jan 6, 2010 at 10:30 AM, Erik Wilde <dret@berkeley.edu> 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)
Received on Thursday, 7 January 2010 17:42:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:13 UTC