HTTP API :: Its Not Possible To Send Data In Body For GET Requests

[lots.0.logs]

Currently there is no way to send data in the body of GET requests using the HTTP API (it gets sent as query args instead). While it may not be a very common use-case, its a valid one nevertheless. I've stumbled upon this while writing an integration for a ​3rd-party API which does not accept data as query args like most APIs typically do.

#37456 is relevant to this issue.

Patch incoming...

[johnbillion]

Thanks for the report, @lots.0.logs.

This is a duplicate of #37364, which is marked as wontfix. Passing body parameters in a GET request is not technically against the HTTP specification but it's certainly not recommended. Most HTTP proxies, for example, will strip the body of GET requests.

There's nothing inherent in the SendinBlue API docs which suggest that the request cannot use a POST request.

[lots.0.logs]

Whether or not you or I, or anyone else for that matter, would recommend it matters not. The only thing that does matter is this:

Passing body parameters in a GET request is not technically against the HTTP specification

There is no harm in allowing this to be configurable as an option. I mean seriously, the greatest thing about WordPress is how extensible it is. Your reasoning for dismissing this as a wontfix goes against the very spirit WordPress.

[dd32]

Although technically supported, I have little want to support it. Just because it can be done, doesn't mean we should encourage it to be done.
I'll defer to @rmccue however, who maintains Requests and who also seems to not want to support it (#37364)

[dmsnell]

My vote also goes against this proposal. It's still possible to support APIs like this (which are very non-standard) by creating a plugin for it. Opening this up in WordPress however would seem to do more to legitimize this behavior when it's very much at risk of breaking things for people in subtle and hard-to-debug ways (such as the mentioned issue with proxies stripping out this data) and it's very non-standard. Would not most people be very suspicious of an API that uses this means for passing data?

[lots.0.logs]

Requests supports this out of the box. We shouldn't make something that is an option in Requests impossible to use without extending the WP_Http class and overriding its request() method. Again, all we have here are a bunch of opinions about disliking HTTP GETrequests being made with a data payload. If you dislike it, then obviously don't do it. The patch I submitted simply makes it possible to use an option which is already supported in the Requests library. It does not change the default behavior of the WP HTTP API in any way.

[rmccue]

Per ​RFC 7231, "A payload within a GET request message has no defined semantics". Handling something with undefined semantics is basically impossible. The reason for this is that until the newest RFCs (723x, aka httpbis), the body wasn't allowed at all (​RFC 2616, 4.3):

A message-body MUST NOT be included in
a request if the specification of the request method (section 5.1.1)
does not allow sending an entity-body in requests.

Both Requests and WP_HTTP were designed for HTTP 1.1 as published in RFC 2616, not the newer 723x. Since there's no defined semantics for GET with a payload, supporting it is tough: would we build data arrays into a body or query strings? Should we send a content-type header? Content-length? etc. Requests doesn't allow it so much as it doesn't disallow it.

The thing here that I think is more relevant is that you can't control the query parameters separately to the body parameters, and the choice is made for you. Requests specifically includes the data_format option to allow overriding this. This option was originally added for the reverse case (setting $data to build a query), but is also useful here.

The main reason I didn't do this is because the parameter is specifically called body, which makes me think it should never be a query string. In hindsight, I think that was wrong, since body is actually used for both.

tl;dr we should probably support data_format

@dd32 Agree?

[dd32]

Replying to rmccue:

tl;dr we should probably support data_format

I'm willing to agree and go with that, if you believe it should be specified by the caller.

I disagree that we should support a body parameter for GET requests though, but I'm willing to allow explicit calls to force it to happen - although I fear it'll cause compatibility issues in the future if we explicitly allow this, and want to move to another library in the future.

[lots.0.logs]

I disagree that we should support a body parameter for GET requests though

Just want to clarify that supporting an explicit body parameter (eg. $args['body']) for GET requests is not and was never the purpose of this enhancement request.

[lots.0.logs]

Hi @rmccue, what's the status on this?