I think it could be useful to return the total number of hits in HTTP
response headers for relevant APIs like search or multisearch.
In my use case, I cache some ES results using varnish. I want to apply
different cache policies (TTL, ...) based on the number of total hits
matching a request. For example, you can choose not to cache requests with
no result, or maybe cache that for 1 minute... Returning this info as a
response header would allow doing this very easily and without parsing the
response body.
Opening up the headers in general would seem to be beneficial, but I am
assuming there is some technical reason not to do so. If not, adding the
number of hits seems like a great place to start.
Here is one project that has an HTTP header issue:
On Friday, January 11, 2013 9:04:20 AM UTC+1, Ivan Brusic wrote:
Opening up the headers in general would seem to be beneficial, but I am
assuming there is some technical reason not to do so. If not, adding the
number of hits seems like a great place to start.
I dont think there is a technical reason. The problem lies in the problem
of anyone having a different use-case (as you need very different logic
depening on your header requirements).
The RestResponse class could easily get methods adding new headers, which
could be parsed by the NettyHttpChannel/HttpChannel class.
I have however not a really good idea, how to make it configurable and
maintainable
If you have any ideas in that regard, it might make sense to add them to
the ticket.
On Friday, January 11, 2013 9:04:20 AM UTC+1, Ivan Brusic wrote:
Opening up the headers in general would seem to be beneficial, but I am
assuming there is some technical reason not to do so. If not, adding the
number of hits seems like a great place to start.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.