- From: <noah_mendelsohn@us.ibm.com>
- Date: Thu, 7 Jan 2010 16:53:15 -0500
- To: Mark Baker <distobj@acm.org>
- Cc: Jan Algermissen <algermissen1971@mac.com>, Erik Wilde <dret@berkeley.edu>, mark@coactus.com, "uri@w3.org" <uri@w3.org>
Mark Baker wrote:
> On Thu, Jan 7, 2010 at 12:15 PM, <noah_mendelsohn@us.ibm.com> wrote:
> > The
> > question is whether the GET method can be meaningfully
> implemented on your
> > resource,
>
> GET is, by design, uniform; it can be meaningfully implemented for all
> resources. The same goes for most HTTP methods with the exception of
> a few defined by the *DAV specifications.
Yeah, you're right. I guess intended by "meaningfully" was sort of "has a
good shot at returning a 200". I agree that's somewhat beside the point
and generally too wooly. Attempting a GET is reasonable on most any URI,
I think, and running a server or proxy that returns at a 303 or even a
404 or 4XX, etc. is indeed "implementing" the method. I still think it's
unlikely that, per httpRange-14 resolution, 200 responses will be
appropriate for geo-scheme URIs.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Mark Baker <distobj@acm.org>
Sent by: mark@coactus.com
01/07/2010 04:20 PM
To: noah_mendelsohn@us.ibm.com
cc: Erik Wilde <dret@berkeley.edu>, Jan Algermissen
<algermissen1971@mac.com>, "uri@w3.org" <uri@w3.org>
Subject: Re: non-HTTP URIs in HTTP requests
Hi Noah,
On Thu, Jan 7, 2010 at 12:15 PM, <noah_mendelsohn@us.ibm.com> wrote:
> The
> question is whether the GET method can be meaningfully implemented on
your
> resource,
GET is, by design, uniform; it can be meaningfully implemented for all
resources. The same goes for most HTTP methods with the exception of
a few defined by the *DAV specifications.
> or more to the point, which status codes are sensible in in
> responses.
Those are also all uniform too AFAIK, but it's good to raise the
httpRange-14 issue (even though I disagree with its resolution).
Mark.
Received on Thursday, 7 January 2010 21:51:19 UTC