org.springframework.web.filter Documentation Differences

This file contains all the changes in documentation in the package org.springframework.web.filter as colored differences. Deletions are shown like this, and additions are shown like this.

If no deletions or additions are shown in an entry, the HTML tags will be what has changed. The new HTML tags are shown in the differences. If no documentation existed, and then some was added in a later version, this change is noted in the appropriate class pages of differences, but the change is not shown on this page. Only changes in existing text are shown here. Similarly, documentation which was inherited from another class or interface is not shown here.

Note that an HTML error in the new documentation may cause the display of other documentation changes to be presented incorrectly. For instance, failure to close a <code> tag will cause all subsequent paragraphs to be displayed differently.

Base class for Filters that perform logging operations before and after a request is processed.

Subclasses should override the beforeRequest(HttpServletRequest, String) and afterRequest(HttpServletRequest, String) methods to perform the actual logging around the request.

Subclasses are passed the message to write to the log in the beforeRequest and afterRequest methods. By default, only the URI of the request is logged. However, setting the includeQueryString property to true will cause the query string of the request to be included also. The payload (body) of the request can be logged via the includePayload flag. Note that this will only log that which is read, which might not be the entire payload.

Prefixes and suffixes for the before and after messages can be configured using the beforeMessagePrefix, afterMessagePrefix, beforeMessageSuffix and afterMessageSuffix properties, @author Rob Harrop @author Juergen Hoeller @author Rossen Stoyanchev @see #beforeRequest @see #afterRequest @since 1.2.5

javax.servlet.Filter that makes form encoded data available throughthrough the {@code ServletRequest.getParameter*()} family of methods during HTTP PUT PUT or PATCH requests.

The Servlet spec requires form data to be available for HTTP POST but but not for HTTP PUT or PATCH requests. This filter intercepts HTTP PUT and PATCH requests where content type is {@code 'application/x-www-form-urlencoded'}, reads form form encoded content from the body of the request, and wraps the ServletRequest ServletRequest in order to make the form data available as request parameters just like it is for HTTP POST requests. @author Rossen Stoyanchev @since 3.1

Filter base class that guaranteesaims to beguarantee just executed oncea single execution per requestrequest dispatch, on any servlet container. It provides a .doFilterInternal method with HttpServletRequest and HttpServletResponse arguments.

As of Servlet 3.0, a filter may be invoked as part of a REQUEST or ASYNC dispatches that occur in separate threads. A filter can be configured in {@code web.xml} whether it should be involved in async dispatches. However, in some cases servlet containers assume different default configuration. Therefore sub-classes can override the method .shouldNotFilterAsyncDispatch() to declare statically if they shouuld indeed be invoked, once, during both types of dispatches in order to provide thread initialization, logging, security, and so on. This mechanism complements and does not replace the need to configure a filter in {@code web.xml} with dispatcher types.

Sub-classes may use .isAsyncDispatch(HttpServletRequest) to determine when a filter is invoked as part of an async dispatch, and use .isAsyncStarted(HttpServletRequest) to determine when the request has been placed in async mode and therefore the current dispatch won't be the last one.

Yet another dispatch type that also occurs in its own thread is ERROR. Sub-classes can override .shouldNotFilterErrorDispatch() if they wish to declare statically if they should be invoked once during error dispatches.

The .getAlreadyFilteredAttributeName method determines how tohow to identify that a request is already filtered. The default implementation implementation isis based on the configured name of the concrete filter instance. @author Juergen Hoeller @author Rossen Stoyanchev @since 06.12.2003

Same contract as for doFilter, but guaranteed to be just invoked once per request within a single request thread. See .shouldNotFilterAsyncDispatch() for details.

Provides HttpServletRequest and and HttpServletResponse arguments instead of thethe default ServletRequest ServletRequest and ServletResponse ones.

Servlet 2.3 Filter that exposes the request to the current thread, through both org.springframework.context.i18n.LocaleContextHolder and RequestContextHolder. To be registered as filter in web.xml.

Alternatively, Spring's org.springframework.web.context.request.RequestContextListener and Spring's org.springframework.web.servlet.DispatcherServlet also expose the same request context to the current thread.

This filter is mainly for use with third-party servlets, e.g. the JSF FacesServlet. Within Spring's own web support, DispatcherServlet's processing is perfectly sufficient. @author Juergen Hoeller @author Rod Johnson @author Rossen Stoyanchev @since 2.0 @see org.springframework.context.i18n.LocaleContextHolder @see org.springframework.web.context.request.RequestContextHolder @see org.springframework.web.context.request.RequestContextListener @see org.springframework.web.servlet.DispatcherServlet

javax.servlet.Filter that generates an ETag value based on the content on the response. This ETag is compared to the If-None-Match header of the request. If these headers are equal, the response content is not sent, but rather a 304 "Not Modified" status instead.

Since the ETag is based on the response content, the response (or org.springframework.web.servlet.View) is still rendered. As such, this filter only saves bandwidth, not server performance. @author Arjen Poutsma @author Rossen Stoyanchev @since 3.0