I'm really torn on stuff like this – as Ryan mentioned, i think it's important to keep Solr abstract from HTTP so we don't wind up with functionality that requires the use of HTTP – but on the other hand things like the API allowing RequestHandlers to specify when/if to allow HTTP Caching are kind of important, so we made special hooks for it
I'm not 100% opposed to SolrDispatchFilter adding the HttpServletRequest into the SolrQueryRequest.getContext() map so custom plugins can use it – but i am 100% opposed to having any requesthandlers/components ship with Solr that require it to work – because those would be completely non-functional for embedded Solr users.
In a lot of cases, i think it probably makes more sense to ask that the client include the information directly as SolrParams – but that generally assumes that a client that knows about Solr conventions is constructing the request – which doesn't work as well now that more and more people want to let end user browser/clients talk directly to Solr and use Velocity or custom response writers to format the response.
My preference would be to write components that might care about these sorts of things to utilize regular SolrParams from the SolrQueryRequest, and then add generic logic to the SolrDispatchFilter to map HTTP Headers to SolrParams. (thus people doing embedded logic can still use the functionality by specifying the appropriate SolrParams)
the key questions with an approach like this would then be fairly simple:
- what type of convention to use for the http header => param naming?
- what should take precedence in the event of name collision: the HTTP Request Query Params, or the HTTP Request Headers?
For people who really want direct access to the HttpServletRequest/Response in their custom plugins (like in
SOLR-1944), and don't care about about embedded solr users, then we can also include them in the Context (no reason to make a bunch of people re-invent the same DIspatchFilter over and over) but i really feel that nothing that ships with Solr should assume it's there and utilize it directly.