Rest: Path components with plus signs are decoded wrong

[nkvoll]

It's perfectly legal for literal '+' characters to appear in the path component on a URL, so for example:

$ curl 'http://localhost:9200/foo+bar' -XPOST
{"error":"InvalidIndexNameException[[foo bar] Invalid index name [foo bar], must not contain the following characters [\\, /, *, ?, \", <, >, |,  , ,]]","status":400}

should not result in an error, since the index name was "foo+bar", not "foo bar".

A workaround until this issue have been fixed is to percent-encode the plus sign using %2B, but this is not optimal, as it should not be required.

[nkvoll]

Looking at the source code, the problem is caused at https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestController.java#L44, where RestUtils.REST_DECODER is used to decode path component values. The REST_DECODER is created for decoding query string components, not path components.

[clintongormley]

As a workaround, percent encoding the plus sign will work.

[paregos]

Hi there Im new to elastic search and I would like to try and fix this bug, if there is any additional information relating to it please let me know.
Thanks

[nik9000]

I don't know about any additional information, though in the time between when this was filed and now we've made a ton of changes. So I'd start by adding tests to make sure it is still a problem and then working from there if it is.

[vlad-at-work]

Hey there, new to elasticsearch. Is this issue still open ?

[monishk7]

curl -X PUT 'http://localhost:9200/foo+bar'
{"error":{"root_cause":[{"type":"invalid_index_name_exception","reason":"Invalid index name [foo bar], must not contain the following characters [ , ", *, \, <, |, ,, >, /, ?]","index_uuid":"na","index":"foo bar"}],"type":"invalid_index_name_exception","reason":"Invalid index name [foo bar], must not contain the following characters [ , ", *, \, <, |, ,, >, /, ?]","index_uuid":"na","index":"foo bar"},"status":400}

'+' is treated as space.
Is there anyone working on this issue ?

[original-brownbear]

This was now fixed in #33164 by correctly differentiating between path and param components of a URL.