[RUBY] : elasticsearch-ruby : Special characters not escaped by the library

Elastic Stack Elasticsearch
1

Hi,

I tried out the elasticsearch Ruby gem today and found that it does not
escape the reserve characters when searching with the query_string query.

As a library providing easy to use search API, wouldn't it be better if the
library escaped the reserve characters in this case?
The API can support a flag, with a sensible default value, to enable or
disable this escaping behavior.

Or is it an explicit design decision that the users themselves have to
escape the reserve characters before sending it to this library?

I am using v0.4.5.

Regards,
Brahmana

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/0bc324f1-dc81-4640-aea0-1a3b08663f20%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

2

imho, || could means OR or literary as it is. So if the library escape for
you, when you mean || to OR, that's wrong.

hth

Jason

On Fri, Jan 10, 2014 at 8:34 AM, Srirang Doddihal om.brahmana@gmail.comwrote:

Hi,

I tried out the elasticsearch Ruby gem today and found that it does not
escape the reserve characters when searching with the query_string query.

As a library providing easy to use search API, wouldn't it be better if
the library escaped the reserve characters in this case?
The API can support a flag, with a sensible default value, to enable or
disable this escaping behavior.

Or is it an explicit design decision that the users themselves have to
escape the reserve characters before sending it to this library?

I am using v0.4.5.

Regards,
Brahmana

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/0bc324f1-dc81-4640-aea0-1a3b08663f20%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAHO4itzMkB6Jv0EkfiXSB7528EPVN4Zwtp96bs5Of93mk%2BRnFg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

3

Sorry for the delayed response.

On Fri, Jan 10, 2014 at 3:43 PM, Jason Wee peichieh@gmail.com wrote:

Elasticsearch Platform — Find real-time answers at scale | Elastic

imho, || could means OR or literary as it is. So if the library escape for

you, when you mean || to OR, that's wrong.

Makes sense. However a character like " (double quote - when used like :
40" tv) will make elasticsearch fail outright with the message saying that
it was unable to parse the query.

Wrong search happening is somewhat ok and can be considered as user not
knowing how to use those operators, but an explicit error is a much worse
user behaviour, isn't it?

Could the library add some such query string sanitize feature?

hth

Jason

On Fri, Jan 10, 2014 at 8:34 AM, Srirang Doddihal om.brahmana@gmail.comwrote:

Hi,

I tried out the elasticsearch Ruby gem today and found that it does not
escape the reserve characters when searching with the query_string query.

As a library providing easy to use search API, wouldn't it be better if
the library escaped the reserve characters in this case?
The API can support a flag, with a sensible default value, to enable or
disable this escaping behavior.

Or is it an explicit design decision that the users themselves have to
escape the reserve characters before sending it to this library?

I am using v0.4.5.

Regards,
Brahmana

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/0bc324f1-dc81-4640-aea0-1a3b08663f20%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/QsVgeOywOkk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CAHO4itzMkB6Jv0EkfiXSB7528EPVN4Zwtp96bs5Of93mk%2BRnFg%40mail.gmail.com
.

For more options, visit https://groups.google.com/groups/opt_out.

--
Regards,
Srirang G Doddihal
Brahmana.

The LIGHT shows the way.
The WISE see it.
The BRAVE walk it.
The PERSISTENT endure and complete it.

I want to do it all ALONE.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CACBGNLt6OkUdEFN%2BFffc-AxfrrbV-2%3Difq5uWMQ1c0h3KsEgbw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

4

The elasticsearch-ruby library is what we call a "low level" client,
closely matching the semantics and notation of the REST API.

So, you pass in exactly the same query as you would into Curl. The only
exception here are e.g. names of document types, which are part of the URL,
and are correctly escaped for you.

Finally, as Jason notes below, no library can "intelligently escape"
special characters for you, because sometimes, ~ is a ~ and sometimes
it's a proximity search expression...

Have a look at
the Elasticsearch Platform — Find real-time answers at scale | Elastic
which might provide a better syntax, and generally avoid the query_string
query for user facing searches, unless warranted by a special use case
(librarians, researchers, etc).

Karel

On Friday, January 10, 2014 1:34:31 AM UTC+1, Srirang Doddihal wrote:

Hi,

I tried out the elasticsearch Ruby gem today and found that it does not
escape the reserve characters when searching with the query_string query.

As a library providing easy to use search API, wouldn't it be better if
the library escaped the reserve characters in this case?
The API can support a flag, with a sensible default value, to enable or
disable this escaping behavior.

Or is it an explicit design decision that the users themselves have to
escape the reserve characters before sending it to this library?

I am using v0.4.5.

Regards,
Brahmana

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/85308030-d0bb-4982-bb32-7424ba0068fe%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

5

Yeah, I agree. It probably is best to keep the ruby library API same as the
server ReST API. If elasticsearch server wants it to be escaped, that's
what this Ruby library expects. Makes sense.

Thank you.

On Wed, Jan 29, 2014 at 3:45 PM, Karel Minařík karel.minarik@gmail.comwrote:

The elasticsearch-ruby library is what we call a "low level" client,
closely matching the semantics and notation of the REST API.

So, you pass in exactly the same query as you would into Curl. The only
exception here are e.g. names of document types, which are part of the URL,
and are correctly escaped for you.

Finally, as Jason notes below, no library can "intelligently escape"
special characters for you, because sometimes, ~ is a ~ and sometimes
it's a proximity search expression...

Have a look at the
Elasticsearch Platform — Find real-time answers at scale | Elastic might provide a better syntax, and generally avoid the query_string
query for user facing searches, unless warranted by a special use case
(librarians, researchers, etc).

Karel

On Friday, January 10, 2014 1:34:31 AM UTC+1, Srirang Doddihal wrote:

Hi,

I tried out the elasticsearch Ruby gem today and found that it does not
escape the reserve characters when searching with the query_string query.

As a library providing easy to use search API, wouldn't it be better if
the library escaped the reserve characters in this case?
The API can support a flag, with a sensible default value, to enable or
disable this escaping behavior.

Or is it an explicit design decision that the users themselves have to
escape the reserve characters before sending it to this library?

I am using v0.4.5.

Regards,
Brahmana

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/QsVgeOywOkk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/85308030-d0bb-4982-bb32-7424ba0068fe%40googlegroups.com
.

For more options, visit https://groups.google.com/groups/opt_out.

--
Regards,
Srirang G Doddihal
Brahmana.

The LIGHT shows the way.
The WISE see it.
The BRAVE walk it.
The PERSISTENT endure and complete it.

I want to do it all ALONE.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CACBGNLt_fsy0fsiyYvPjQRsCW740E9oDto%2BBXpiDSbn9QpXFRw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.