Hi, Paul Bonser wrote: > On 7/23/08, Kevin Jackson <[EMAIL PROTECTED]> wrote: >>>> Although no one uses it, GET (and even HEAD) requests are not >> >> forbidden from having bodies. (I think.) >> > >> > That does break the whole REST idea, though, doesn't it? >> >> >> Yeah you'd lose 'buzzword compliance' at that point :) > > Yeah. I suppose a better argument is that I *know* that POST requests > are not forbidden from having bodies. I don't see why doing it with a > GET would make it any better. There are libraries out there that > probably don't support a body with a GET request. > > No one uses it because it doesn't make sense to use it.
Sorry for the late answer, but I did not get in touch with the multi-key support earlier. I would actually prefer using GET with a request body for fetching view results with multiple keys, since otherwise the semantics [1] of POST requests are violated. Starting with using the HTTP methods in a different meaning then they have been developed for, just because of potential implementation details, may open a can of worms, breaking the whole HTTP standard. Sending GET request including data is actually not an issue, at least with curl (curl -X GET --data-binary 'Some content' http://couch/), or the PHP HTTP stream wrapper. (Just quickly tested those two). But it still might be an issue with proxies, like, for example, lighttpd always responds with a "400 - Bad Request" to such requests. I still think that semantics of such requests really matter - especially when they are part of the public API. If some tool does not support GET with a request body, it is actually a bug in that tool and should be fixed there [2]: > A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request. And, if implemented with the wrong semantics the RFC clearly states, that the implementing server breaks with the RFC [3]: > The methods GET and HEAD MUST be supported by all general-purpose servers. All other methods are OPTIONAL; however, if the above methods are implemented, they MUST be implemented with the same semantics as those specified in section 9. If GET allows the inclusion of an entity-body is actually unspecified, as you can see in section #9.3. Otherwise it might still be the better way to go with URL parameters, as proposed in the first patch, even this would invoke limits on the number of used keys. Sorry for nitpicking on semantics, I really prefer the feature and, of course, the work on CouchDB in general - but it simply does not feel right violating the RFC just to bypass potential limits. [1] http://tools.ietf.org/html/rfc2616#section-9.5 [2] http://tools.ietf.org/html/rfc2616#section-4.3 [3] http://tools.ietf.org/html/rfc2616#section-5.1.1 -- Kore Nordmann (GPG 0xDDC70BBB) http://kore-nordmann.de/portfolio.html
signature.asc
Description: OpenPGP digital signature
