Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GET body not sended #354

Closed
LaG1924 opened this issue Aug 25, 2021 · 10 comments
Closed

GET body not sended #354

LaG1924 opened this issue Aug 25, 2021 · 10 comments
Labels
question Further information is requested

Comments

@LaG1924
Copy link

LaG1924 commented Aug 25, 2021

tl;dr: when request type is GET and Content-Type is Json, "Content-Length" is non-zero but body not send.

Hello. This is my first experience with this library, so it's maybe just me using this library's API in the wrong way.
I'm trying to make a test GET request, but it just does not work (no PrintString node on fail/completed callback). So, I started investigation:
In logs was the next messages:

LogVaRest: Request (json): GET http://localhost/api/test
JSON(
{
    "test": "test"
}
)JSON
...
LogHttp: Warning: 000001712E3C4100: invalid HTTP response code received. URL: http://localhost/api/test, HTTP code: 0, content length: 0, actual payload size: 0
LogHttp: Warning: 000001712E3C4100: request failed, libcurl error: 52 (Server returned nothing (no headers, no data))
LogHttp: Warning: 000001712E3C4100: libcurl info message cache 0 (  Trying ::1...)
LogHttp: Warning: 000001712E3C4100: libcurl info message cache 1 (TCP_NODELAY set)
LogHttp: Warning: 000001712E3C4100: libcurl info message cache 2 (  Trying 127.0.0.1...)
LogHttp: Warning: 000001712E3C4100: libcurl info message cache 3 (TCP_NODELAY set)
LogHttp: Warning: 000001712E3C4100: libcurl info message cache 4 (Connected to localhost (127.0.0.1) port 80 (#57))
LogHttp: Warning: 000001712E3C4100: libcurl info message cache 5 (Empty reply from server)
LogHttp: Warning: 000001712E3C4100: libcurl info message cache 6 (Connection #57 to host localhost left intact)

After spending some time debugging the web server I figured out that it was a malformed request send by the library:

GET /api/test HTTP/1.1
Host: localhost
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: application/json
User-Agent: TestProj/++UE4+Release-4.26-CL-15973114 Windows/10.0.19043.1.256.64bit
Content-Length: 21

It's declaring the request's "Content-Length" header but does not send the body (request end with two newlines), so the web server is still waiting for data and not sending a response.

But for POST (I didn't test other methods) it successfully sends the body with the correct "Content-Length" header.
For Content-Type "x-www-form-urlencoded (URL)" it sets "Content-Lenth: 0", so it works too.

bp_varest

@ufna ufna added the question Further information is requested label Aug 25, 2021
@ufna
Copy link
Owner

ufna commented Aug 25, 2021

GET requests with json content type have no body. You should use POST, or x-www-form-urlencoded content type.

@LaG1924
Copy link
Author

LaG1924 commented Aug 25, 2021

I see. Yes, that does make sense, but what should I do if API requires to be every request in JSON? Even empty GET requests (in that case body must be only {}). I tested such behavior in python (with requests library) and it works perfectly.

And I just found #99 which sounds very familiar.

@ufna
Copy link
Owner

ufna commented Aug 26, 2021

It's not a way REST api should be used, and it's not supported with json content type right now in the engine itself. Please provide an example of public API you're trying to work with.

Also you can check x_www_form_urlencoded_body request type, maybe it'll help you.

@LaG1924
Copy link
Author

LaG1924 commented Aug 26, 2021

https://developers.home-assistant.io/docs/api/rest/
That was my mistake about "body is {}". Actually, that's API needs just "content-type" to be set to "application/json". So, can I just override "content-type" header for x-www-form-urlencoded?

@ufna
Copy link
Owner

ufna commented Aug 26, 2021

I've checked the api, and you shouldn't pass any parameters in json or body form to server for GET requests

@LaG1924
Copy link
Author

LaG1924 commented Aug 26, 2021

Yes, and I already wrote about that.
But I still have to use application/json as Content-Type header value. I believe this is easily solvable.
I think you can close the issue.

@ufna
Copy link
Owner

ufna commented Aug 26, 2021

Got the idea. Please try this in VaRestRequestJSON.cpp:

image

@LaG1924
Copy link
Author

LaG1924 commented Aug 26, 2021

Unfortunately, I hoped to use this library as a quick-and-dirty solution to prototype some features before using C++. But for now (especially if I will need to modify the plugin's code) it will be simpler for me to implement features directly in code, not in blueprints.

If you still want me to test these changes, then I can find time to do this... next week?

@ufna ufna closed this as completed in acbad67 Aug 26, 2021
ufna added a commit that referenced this issue Aug 26, 2021
@ufna
Copy link
Owner

ufna commented Aug 28, 2021

@LaG1924 I've sent an update to Marketplace, hope it'll be processed soon (for UE 4.26 and UE 4.27)

@Suundumused
Copy link

my VaRest worked for 3 days, now "GET" stopped permanently

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants