[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535248
]
Thomas Peuss commented on SOLR-127:
-----------------------------------
ad 1.)
I have thought about that as well. We should make it configurable. But I do not
know where the best place is for the configuration.
ad 2.)
getVersion() delivers a long - how should that ever be converted to w/?
According to W3C a weak ETag looks like this: W/"xyzzy". We always generate
ETags like "xyzzy". So no problem here. Even "W/xyzzy" would be a strong ETag.
Hashing of the version is a good idea. I add that. But be aware that generating
a hash consumes a lot of extra CPU cycles...
ad 3.)
As the answer to a request is always the same when the index is not changed it
is OK to have the same ETag for all requests IMHO. The ETag has not to be
exclusive per request URL. The ETag only allows the browser to send requests
like "only execute when changed". And the ETag only changes when the index has
changed.
ad 4.)
I have thought about that as well. The problem here is that we have POSTs that
change the index and POSTs that do not change the index. The semantics are
according to W3C. Here a snippet from
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html (section 14.26):
"Instead, if the request method was GET or HEAD, the server SHOULD respond with
a 304 (Not Modified) response, including the cache- related header fields
(particularly ETag) of one of the entities that matched. For all other request
methods, the server MUST respond with a status of 412 (Precondition Failed)."
The idea behind that seems to be that POSTs are for changing things. But we can
ignore that of course.
ad 5.)
Maybe we should not emit cache related headers for POSTs at all?
> Make Solr more friendly to external HTTP caches
> -----------------------------------------------
>
> Key: SOLR-127
> URL: https://issues.apache.org/jira/browse/SOLR-127
> Project: Solr
> Issue Type: Wish
> Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch
>
>
> an offhand comment I saw recently reminded me of something that really bugged
> me about the serach solution i used *before* Solr -- it didn't play nicely
> with HTTP caches that might be sitting in front of it.
> at the moment, Solr doesn't put in particularly usefull info in the HTTP
> Response headers to aid in caching (ie: Last-Modified), responds to all HEAD
> requests with a 400, and doesn't do anything special with If-Modified-Since.
> t the very least, we can set a Last-Modified based on when the current
> IndexReder was open (if not the Date on the IndexReader) and use the same
> info to determing how to respond to If-Modified-Since requests.
> (for the record, i think the reason this hasn't occured to me in the 2+ years
> i've been using Solr, is because with the internal caching, i've yet to need
> to put a proxy cache in front of Solr)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
