How send GET-request with a body?

Questions / Help
,
1

Hello there,
Here I have this request in curl:

curl
-H "AUTHENTICATION: HMAC GPLDIS8H7N5KY8DG:c6881c8bbcee2daceb5d8c2bb54078702bca23d828d7468afeb2f6ed0f25366f:1549890568"
-X GET
-d '{"customer_id":"Chrome","customer_ip":"127.0.0.1"}' 'https://testrest.vload.expert/voucher/validate/2698937783822253/Chrome/11234576536'

This is bad practice with using body in GET-request, unfortunately it is not my choice. So, how can I send it using some Elixir/Erlang library?
I was trying do it by using HTTPoison, HTTPotion in Elixir. And httpc in erlang, but httpc even don’t send GET-request if I put body to it:
:httpc.request(:get, {url, headers, 'text/plain', 'body'}, [], [])

2

Not only bad style, but also absolutely useless, as it is not allowed to change the servers response.

Because of this proxies might decide to not forward the body.

And you away, :httpc wouldn’t even send a GET request. Could you tell us what it does instead? Does it crash? Returns an error? Sends a POST?

4 
:httpc.request(:get, {vload_url, valid_headers, 'text/plain', '{"customer_id":"Chrome","customer_ip":"127.0.0.1"}'}, [], [])  Bug Bug ..!!** (FunctionClauseError) no function clause matching in :httpc.request/5

    The following arguments were given to :httpc.request/5:

        # 1
        :get

        # 2
        {'----',
         [
           {'AUTHENTICATION',
            'HMAC: ----'}
         ], 'text/plain', '{"customer_id":"Chrome","customer_ip":"127.0.0.1"}'}

        # 3
        []

        # 4
        []

        # 5
        :default

    (inets) httpc.erl:149: :httpc.request/5

If change method to the POST, it will send. But it is not will be working because of someone wrote API only for a body with GET.

5

It htrows an error, Okay.

So :httpc doesn’t allow sending a body with GET request, you can not change that. (well you could “fork” :httpc and allow it, with a very high chance its just adding/removing some condition to a guard).

Have you tried HTTPotion.request? I consider the code ugly, and only skimmed it, but on a first glance I haven’t seen any guards against it. If though :hackney does validate the request you are out of luck again. Then you need to check the same for HTTPoison and :ibrowse.

And of course you can use :tesla, it uses :httpc, :hackney or :ibrowse as backend though.

Last but not least, you can of course just omit the body, as its presence or content shouldn’t have any effect on the response, if though it does please point the authors of the API to the RFC:

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 GET does not define any semantics.

Last but not least, you have the choice to simply use System.cmd to curl any request you want until you find a way to convince the API-Designer to repair their product…

6

“Not allowed to” meet “real world”, “real world” meet “not allowed to” :wink:

I agree, obviously, that it is a HORRIBLE design for an API, in fact it is just not HTTP. And I would definitely point that out to the API designers, especially the part about proxies dropping it.

But ultimately, sometimes, we have to use non-compliant APIs.

2 Likes
7

As far as HTTPoison builds on hackney, it’s possible to handle such unconventional request. It’s not documented well on HTTPoison page, but works :slight_smile:.

iex(11)> request2 = %HTTPoison.Request{                                                                                                                            
...(11)>             method: :get,                                                                                                                                 
...(11)>             headers: [{"AUTHENTICATION", "HMAC GPLDIS8H7N5KY8DG:c6881c8bbcee2daceb5d8c2bb54078702bca23d828d7468afeb2f6ed0f25366f:1549890568"}],                      
...(11)>             body: "{\"customer_id\":\"Chrome\",\"customer_ip\":\"127.0.0.1\"}",                                                                           
...(11)>             url: "https://testrest.vload.expert/voucher/validate/2698937783822253/Chrome/11234576536"                                                     
...(11)> }
iex(12)> HTTPoison.request(request2)
4 Likes
8

BTDT, but even worse… The underlying server expected some headers in exact order, no more, no less…

Still, we were able to convince the API provider to change this behaviour, as we consumed the API via mobile networks which again were force proxies and the proxies of course touched the headers.

So telling the provider about problems might help them to see issues they didn’t know to exist.

4 Likes
9

Oh absolutely, I had to deal with one with case-sensitive headers, which presents some issues with Elixir. (Tests, IIRC, check case and want all lower…)

Funny thing is, we owned the service in question, and were afraid to even try to touch the code. In fact, that’s one extremely minor example of why the Elixir program in question came into existence.

But yeah, just to reiterate: do point it out to the devs, they may well want to fix it.

3 Likes
10

This RFC is now obsolete. It was replaced by RFC 7230-7237. And this RFC allows to send body with GET request.

Request message
framing is independent of method semantics, even if the method does
not define any use for a message body

A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.

It is still not a good idea, but it doesn’t contradict HTTP/1.1 spec

2 Likes
11

I should take a closer look at those obseletion markers at the top :wink:

Neither does the fact that some clients do not allow to create such a request.

Anyway, there are clients available in elixir that allow GET with body as pointed out earlier. It’s not necessarily convenient to do so :wink:

And still, third party issues exist. A proxy dropping the request does not act against the spec either and still makes it impossible to use the service. This is something that could cost the API provider money and they should be made aware of the issue.

2 Likes
12

Blimey, how I missed it(
Thank’s