orbitdb-archive / orbit-db-http-api

A HTTP API Server for the OrbitDB distributed peer-to-peer database
MIT License
37 stars 11 forks source link

Content type error #27

Closed JoaoFSCruz closed 4 years ago

JoaoFSCruz commented 4 years ago

Hi everyone :wave:. I changed to the underdevelopment repository as it has a lot more features and responsiveness.

The spring server I implemented has not changed between the substitution of the orbitd-db-http-api in use. But now I'm getting an error on the server when performing a get request by id (where the response is empty since it is an existence check):

org.springframework.web.client.RestClientException: Could not extract response: no suitable HttpMessageConverter found for response type [class com.fasterxml.jackson.databind.JsonNode] and content type [text/html;charset=utf-8]

And I verified with Wireshark too:

HTTP/1.1 200 OK content-type: text/html; charset=utf-8 cache-control: no-cache content-length: 2 accept-ranges: bytes Date: Thu, 09 Apr 2020 08:42:38 GMT Connection: keep-alive []

I managed to get a solution for this, by accepting the response as String and parsing it to JSON. But I guess it's not was it is supposed to be returning :wink:.

phillmac commented 4 years ago

Could you clarify which route you were using? e.g. GET /db/Qm....... ? Also can you please see if you can replicate the problem via curl or wget and paste the output here ?

JoaoFSCruz commented 4 years ago

Sorry, @phillmac.

I had this problem with the GET /db/{dbname}/{item}, where the item does not exist. It's to check if an item already exists with a given id.

With curl, it responds with the empty array.

With wget, I can retrieve the empty array to a file and the output is:

--2020-04-09 10:29:53-- http://localhost:3000/db/zdpuAqAC4s7UUJNR7fzV1QQ5Lu2DDg97ge18nYFfPSRncsWq3%2Fload-test/1 Resolving localhost (localhost)... 127.0.0.1 Connecting to localhost (localhost)|127.0.0.1|:3000... connected. HTTP request sent, awaiting response... 200 OK Length: 2 [text/html] Saving to: ‘1’ 1 100%[===================>] 2 --.-KB/s in 0s
2020-04-09 10:29:53 (203 KB/s) - ‘1’ saved [2/2]

Note the content type is [text/html] when I think it should be [application/json] to preserve the consistency of the API (as [application/json] is used on all other endpoints).

phillmac commented 4 years ago

So, as it turns out, pure strings are really troublesome to deal with, because the content type detection system decides that they should elicit a text type response ☹️ That being said, I think I've finally got this problem sorted, this being the third time I've had to deal with this specific bit of code. Try the most recent docker image, hopefully it should resolve this. As a side note, I've modified the response a little so it now throws a 404 error rather then just an empty array response. Hopefully that might be a bit easier to deal with?

JoaoFSCruz commented 4 years ago

Took a look at your commits and it surely helps! I'm not changing version right now as it may break other services coupled to mine. This was more of a heads up :smile:

Thanks a lot for the quick responses and fixes!

phillmac commented 4 years ago

No worries :grin: