lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Confluence)" <conflue...@apache.org>
Subject [CONF] Apache Solr Reference Guide > RequestDispatcher in SolrConfig
Date Tue, 16 Jul 2013 18:13:00 GMT
Space: Apache Solr Reference Guide (https://cwiki.apache.org/confluence/display/solr)
Page: RequestDispatcher in SolrConfig (https://cwiki.apache.org/confluence/display/solr/RequestDispatcher+in+SolrConfig)

Change Comment:
---------------------------------------------------------------------
SOLR-2079

Edited by Hoss Man:
---------------------------------------------------------------------
{section}
{column:width=75%}
The {{requestDispatcher}} element of {{solrconfig.xml}} controls the way the Solr servlet's
{{RequestDispatcher}} implementation responds to HTTP requests. Included are parameters for
defining if it should handle {{/select}} urls (for Solr 1.1 compatibility), if it will support
remote streaming, the maximum size of file uploads and how it will respond to HTTP cache headers
in requests.
{column}
{column:width=25%}
{panel}
Topics in this section:
{toc:maxLevel=2}
{panel}
{column}
{section}

h2. {{handleSelect}} Element

{note}
{{handleSelect}} is for legacy back-compatibility; those new to Solr do not need to change
anything about the way this is configured by default.
{note}

The first configurable item is the {{handleSelect}} attribute on the {{<requestDispatcher>}}
element itself. This attribute can be set to one of two values, either "true" or "false".
It governs how Solr responds to requests such as {{/select?qt=XXX}}. The default value "false"
will ignore requests to {{{/select}} if a requestHandler is not explicitly registered with
the name {{/select}}. A value of "true" will route query requests to the parser defined with
the {{qt}} value.

In recent versions of Solr, a {{/select}} requestHandler is defined by default, so a value
of "false" will work fine. See the section [RequestHandlers and SearchComponents in SolrConfig]
for more information.

{code:xml|borderStyle=solid|borderColor=#666666}
<requestDispatcher handleSelect="true" >
    ...
</requestDispatcher>
{code}

h2. {{requestParsers}} Element

The {{<requestParsers>}} sub-element controls values related to parsing requests. This
is an empty XML element that doesn't have have any content, only attributes. 

The attribute {{enableRemoteStreaming}} controls whether remote streaming of content is allowed.
If set to {{false}}, streaming will not be allowed. Setting it to {{true}} (the default) lets
you specify the location of content to be streamed using {{stream.file}} or {{stream.url}}
parameters.

If you enable remote streaming, be sure that you have authentication enabled. Otherwise, someone
could potentially gain access to your content by accessing arbitrary URLs. It's also a good
idea to place Solr behind a firewall to prevent it being accessed from untrusted clients.

The attribute {{multipartUploadLimitInKB}} sets an upper limit in kilobytes on the size of
a document that may be submitted in a multi-part HTTP POST request. The value specified is
multiplied by 1024 to determine the size in bytes.

The attribute {{formdataUploadLimitInKB}} sets a limit in kilobytes on the size of form data
(application/x-ww-form-urlencoded) submitted in a HTTP POST request, which can be used to
pass request parameters that will not fit in a URL.

The attribute {{addHttpRequestToContext}} can be used to indicate that the original {{HttpServletRequest}}
object should be included in the context map of the {{SolrQueryRequest}} using the key {{httpRequest}}.
 This {{HttpServletRequest}} is not be used by any Solr components, but may be useful when
developing custom plugins.

{code:xml|borderStyle=solid|borderColor=#666666}
<requestParsers enableRemoteStreaming="true" 
                multipartUploadLimitInKB="2048000"
                formdataUploadLimitInKB="2048"
                addHttpRequestToContext="false" 
/>
{code}

h2. {{httpCaching}} Element

The {{<httpCaching>}} element controls HTTP cache control headers. Do not confuse these
settings with Solr's internal cache configuration. This element controls caching of HTTP responses
as defined by the W3C HTTP specifications.

This element allows for three attributes and one sub-element. The  attributes of the {{<httpCaching>}}
element control whether a 304 response to a GET request is allowed, and if so, what sort of
response it should be. When an HTTP client application issues a GET, it may optionally specify
that a 304 response is acceptable if the resource has not been modified since the last time
it was fetched.

|| Parameter || Description ||
| never304 | If present with the value {{true}}, then a GET request will never respond with
a 304 code, even if the requested resource has not been modified. When this attribute is set
to true, the next two attributes are ignored. Setting this to true is handy for development,
as the 304 response can be confusing when tinkering with Solr responses through a web browser
or other client that supports cache headers. |
| lastModFrom | This attribute may be set to either {{openTime}} (the default) or {{dirLastMod}}.
The value {{openTime}} indicates that last modification times, as compared to the If-Modified-Since
header sent by the client, should be calculated relative to the time the Searcher started.
Use {{dirLastMod}} if you want times to exactly correspond to when the index was last updated
on disk. |
| etagSeed | This value of this attribute is sent as the value of the {{ETag}} header. Changing
this value can be helpful to force clients to re-fetch content even when the indexes have
not changed---for example, when you've made some changes to the configuration. |

{code:xml|borderStyle=solid|borderColor=#666666}
<httpCaching never304="false"
    lastModFrom="openTime"
    etagSeed="Solr">
    <cacheControl>max-age=30, public</cacheControl>
</httpCaching>
{code}

h3. {{cacheControl}} Element

In addition to these attributes, {{<httpCaching>}} accepts one child element: {{<cacheControl>}}.
The content of this element will be sent as the value of the Cache-Control header on HTTP
responses. This header is used to modify the default caching behavior of the requesting client.
The possible values for the Cache-Control header are defined by the HTTP 1.1 specification
in [Section 14.9|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9].

Setting the max-age field controls how long a client may re-use a cached response before requesting
it again from the server. This time interval should be set according to how often you update
your index and whether or not it is acceptable for your application to use content that is
somewhat out of date. Setting {{must-revalidate}} will tell the client to validate with the
server that its cached copy is still good before re-using it. This will ensure that the most
timely result is used, while avoiding a second fetch of the content if it isn't needed, at
the cost of a request to the server to do the check.

{scrollbar}


Stop watching space: https://cwiki.apache.org/confluence/users/removespacenotification.action?spaceKey=solr
Change email notification preferences: https://cwiki.apache.org/confluence/users/editmyemailsettings.action


    

Mime
View raw message