[
https://issues.apache.org/jira/browse/SOLR-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901546#action_12901546
]
Hoss Man commented on SOLR-2079:
--------------------------------
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.
> Expose HttpServletRequest object from SolrQueryRequest object
> -------------------------------------------------------------
>
> Key: SOLR-2079
> URL: https://issues.apache.org/jira/browse/SOLR-2079
> Project: Solr
> Issue Type: Improvement
> Components: Response Writers, search
> Reporter: Chris A. Mattmann
> Fix For: 3.1
>
> Attachments: SOLR-2079.Quach.Mattmann.082310.patch.txt
>
>
> This patch adds the HttpServletRequest object to the SolrQueryRequest object.
> The HttpServletRequest object is needed to obtain the client's IP address for
> geotargetting, and is part of the patches from W. Quach and C. Mattmann.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
