incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kore Nordmann <m...@kore-nordmann.de>
Subject Re: [PATCH] Views: Multiple keys
Date Tue, 04 Nov 2008 22:41:33 GMT
Hi,

Paul Bonser wrote:
> On 7/23/08, Kevin Jackson <foamdino@gmail.com> 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


Mime
View raw message