lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-2079) Expose HttpServletRequest object from SolrQueryRequest object
Date Mon, 23 Aug 2010 19:16:24 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message