Leading backslash important in Elastic Cloud but not in the official docker container


(Rob Swartenbroekx) #1

POST indexname/_update_by_query HTTP/1.1 is failing on Elastic Cloud
POST /indexname/_update_by_query HTTP/1.1 is working on Elastic Cloud

POST indexname/_update_by_query HTTP/1.1 is working on the official docker container
POST /indexname/_update_by_query HTTP/1.1 is working on the official docker container

Considering I'm using docker for testing, I would like the same behaviour on my Docker container than on Elastic Cloud. Anyone an idea how to achieve this?

Thx


(Mark Walkom) #2

Where are you running these commands from?


(Rob Swartenbroekx) #3

From a java application that is running locally on my Mac. The docker containers are running also locally on my Mac.


(Mark Walkom) #4

Can you show the logs?


(Rob Swartenbroekx) #5

Caused by: org.elasticsearch.client.ResponseException: POST https://url:9243indexname/_update_by_query: HTTP/1.1 400 BAD_REQUEST


(David Pilato) #6

Can you share your Java code? Which Java client are you using?


(Rob Swartenbroekx) #7

You are focussing on the wrong level. My question is not why it isn't working with or without the backslash. But why the behaviour of the same request is handled differently by the docker container than by the elastico cloud service.

The following lines are captured by WireShark

"38773","228.447656","127.0.0.1","127.0.0.1","HTTP","568","POST /queue_1/_update_by_query HTTP/1.1 (text/plain)"
"38923","450.564002","127.0.0.1","127.0.0.1","HTTP","567","POST queue_1/_update_by_query HTTP/1.1 (text/plain)"

Both lines are giving a 200 when they are run against docker. If similar requests are run against elastic cloud. Only the first line (with the leading slash would work). My question is not why is the slash needed, but rather why is the docker behaving differently than elastic search. Because that way I will notice errors against this in my integration tests.

But to answer your question. At the moment I'm using the org.elasticsearch.client.Restclient from org.elasticsearch.client:elasticsearch-rest-client:5.6.4. I'm using org.elasticsearch.client.RestClient#performRequest(java.lang.String, java.lang.String, java.util.Map<java.lang.String,java.lang.String>, org.apache.http.Header...). And it's in the endpoint parameter that should start with a slash


(David Pilato) #8

I'd always use a trailing / at the beginning of a URL.

The main difference that "might" explain that behavior though is that cloud has a proxy in front of the service which docker does not have.
But I'm almost sure that if you try all that with elastic cloud enterprise you will see the same behavior as for elastic cloud as both have a proxy.

That being said, this might be viewed as a bug in the Low Level REST Client as we should never allow sending requests without the leading /. IMHO.


(Rob Swartenbroekx) #9

I don't mind to put always / at the beginning of a URL. It bothers me that if I forget it, that my integration tests wouldn't fail, because they are run against the docker container.

I would only notice my error when I test it manually against elastic cloud


(system) #10

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.