- 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