GET requests with body not supported about patron HOT 6 CLOSED

Yes, we drop the body when building a GET request with libcurl. I did some research on GET with a body this afternoon and I think it is more accurate to say that the HTTP spec does not preclude a body in a GET request, but neither does it specify the semantics for such a thing. I ran across this quote from Roy Fielding while researching the topic:

Server semantics for GET, however, are restricted such that a body,
if any, has no semantic meaning to the request. The requirements
on parsing are separate from the requirements on method semantics.

So, yes, you can send a body with GET, and no, it is never useful
to do so.

Given this I am inclined to leave Patron the way it is. I am, however, open to implementing more methods (such as the methods described in the WebDAV spec) if that would be useful.

~p

from patron.

Curl supports GET with body:

curl -X GET localhost:4567/echo -d name=mislav

That means it's supported with libcurl. The only reason why Patron doesn't support it because it explicitly chooses to block it. I don't think that's such a good call because the spec never explicitly says "Thou shalt not send body with GET requests"; it simply leaves this a gray area.

For an example of GET with body in the wild: elasticsearch

$ curl -XGET http://localhost:9200/twitter/_search?pretty=true -d '{
    "query" : {
        "range" : {
            "post_date" : {
                "from" : "2009-11-15T13:00:00",
                "to" : "2009-11-15T14:30:00"
            }
        }
    }
}'

This is actually a pretty good use case. It queries the search index but uses the body since the query might be too large to fit in a URL. The request is still idempotent and still can be HTTP-cached.

from patron.

I never disputed that libcurl supports GET with a body. I said "we drop the body when building a GET request with libcurl"; in other words Patron ignores the body when creating the request with libcurl. I am clearly aware of the technical issues.

While the spec doesn't explicitly forbid GET requests with a body, as Fielding makes clear the spec does not define server semantics for such a request. Therefore a server that implements some semantics for GET with a body is by definition implementing non-standard behavior. The above example is abusing GET for no clear benefit. If you really need to send a body for something like that use POST. That is what it is there for.

The bottom line is that I have limited time to devote to Patron and I am not going to spend it implementing corner-case features.

from patron.

Well, it's used by Elastic Search and ArchLinux's AUR API. Would you at least accept a patch?

from patron.

I already have: 4eaaf3e

from patron.

Thanks!

from patron.