0.4.8 transport.perform_request with curb body is no longer parsed JSON #36
Comments
|
Seems to be specific to the Curb based transport... Will look into it. |
|
The culprit is obviously 80c48dd |
|
That would be a good guess... curl response from the call to GET /_aliases does return as application/json so should be ok. should the code be looking for Content-Type, not content-type in the headers hash? |
Good catch! Faraday "normalizes" the header like this, but obviously the Curb transport doesn't go through that... |
|
This seems to be the problem: client = ::Curl::Easy.new
=> #<Curl::Easy>
client.url = 'http://localhost:9200'
=> "http://localhost:9200"
client.http(:get)
=> true
client.header_str
=> "HTTP/1.1 200 OK\r\nContent-Type: application/json; charset=UTF-8\r\nContent-Length: 311\r\n\r\n"
client.headers
=> {} |
|
Related: taf2/curb#184 |
|
it looks like #headers is for setting headers on the request, not getting them from the response |
|
Yes, but in any case seems like there's no version of headers parsed as a Hash in Curb yet. Let's add the check for |
…transport
Because of the change introduced in elasticsearch/elasticsearch-ruby#80c48dd,
responses from the Curb transport were not correctly deserialized into Hash from JSON string.
That's because we actually haven't returned any response headers in the `Curb#perform_request` method.
Since Curb doesn't return any response headers as a Hash (see related), we simply check for:
header_str =~ /\/json/
in `Curb#perform_request`.
This seems to have noticeable impact on the raw performance, adding ~ 10ms to _mean_ times
when running the client benchmark test. On the other hand, previously we did check body
whether it "looks like a JSON", which definitely has been influencing the end times,
so hopefully it balances out.
Once Curb adds response headers as a Hash, the code should change appropriately.
Closes: #36
Related: taf2/curb#184
…transport
Because of the change introduced in elasticsearch/elasticsearch-ruby#80c48dd,
responses from the Curb transport were not correctly deserialized into Hash from JSON string.
That's because we actually haven't returned any response headers in the `Curb#perform_request` method.
Since Curb doesn't return any response headers as a Hash (see related), we simply check for:
header_str =~ /\/json/
in `Curb#perform_request`.
This seems to have noticeable impact on the raw performance, adding ~ 10ms to _mean_ times
when running the client benchmark test. On the other hand, previously we did check body
whether it "looks like a JSON", which definitely has been influencing the end times,
so hopefully it balances out.
Once Curb adds response headers as a Hash, the code should change appropriately.
Closes: #36
Related: taf2/curb#184
|
Closed in ecfe780 |
Since upgrading to 0.4.8, requests the go via the curb transport are returning a string body, instead of a hash body as in 0.4.7.
I'm seeing
client.indices.get_aliasesreturning a string, instead of a hash for example.The text was updated successfully, but these errors were encountered: