The CookieFilter keeps a
record of all the browser cookies associated with a given session.
This can be
used to make the user's cookies "mobile" as follows. A user's cookies
are normally stored with the browser being used, on the user's machine.
If the user runs a different browser or goes to a different machine, the
user's cookies will not be there. Instead, the user can access the web
via a proxy that keeps all their cookies. No matter which browser the
user chooses or machine the user is at, a proxy running with the
CookieFilter will automatically remember and add in their
appropriate cookies. The CookieFilter also supports
multiple, concurrent users, keeping each user's cookies separate.
All "Set-Cookie" HTTP response headers are filtered out and saved in
the local storage. "Set-Cookie" headers are not transmitted back to the
client.
Requests from the client have the appropriate "Cookie" headers added.
Users can retrieve, edit, and delete their own cookies.
JavaScript code that sets cookies is not handled by this
filter, since the code only runs on the client computer, not on the proxy.
For instance: document.cookie = "userid=778287312". Any and
all Javascript is passed unchanged by this filter.
This filter works in both a session-based and a non-session-based
fashion. If sessions are used, cookies are kept with respect to the
session associated with a user. If sessions are not used, all cookies
are kept in one pile for all users. The latter case is valid if, say,
only one user is using the proxy running the CookieFilter.
Properties:
session
The request property to find the session id.
Defaults to "SessionID"
nosession
The name of the session to use if no session
id is found. defaults to "common".
admin
A URL prefix that causes status information to
be placed in the request properties.
filter(Request request,
MimeHeaders headers,
byte[] content)
Returns the original content, since this filter does not change
content; it changes the headers.
shouldFilter(Request request,
MimeHeaders headers)
Saves all "Set-Cookie" headers from the target in the client's local
storage, then removes those headers before allowing the response to
go back to the client.
server - The HTTP server that created this Handler.
Typical Handlers will use Server.props
to obtain run-time configuration information.
prefix - A prefix that this Handler may prepend to all
of the keys that it uses to extract configuration information
from Server.props. This is set (by the Server
and ChainHandler) to help avoid configuration parameter
namespace collisions.
For example, if a Handler uses the property
"account", and the specified prefix is "bank.", then the
Handler should actually examine the property
"bank.account" in Server.props.
Returns:
true if this Handler initialized
successfully, false otherwise. If
false is returned, this Handler
should not be used.
request - The Request object that represents the HTTP
request.
Returns:
true if the request was handled. A request was
handled if a response was supplied to the client, typically
by calling Request.sendResponse() or
Request.sendError.
Throws:
IOException - if there was an I/O error while sending the response to
the client. Typically, in that case, the Server
will (try to) send an error message to the client and then
close the client's connection.
The IOException should not be used to silently
ignore problems such as being unable to access some
server-side resource (for example getting a
FileNotFoundException due to not being able
to open a file). In that case, the Handler's
duty is to turn that IOException into a
HTTP response indicating, in this case, that a file could
not be found.
Saves all "Set-Cookie" headers from the target in the client's local
storage, then removes those headers before allowing the response to
go back to the client. The client never sees cookies on their local
machine.
headers - The MIME headers generated by the Handler.
content - The output from the Handler that this
Filter may rewrite.
Returns:
The rewritten content. The Filter may return
the original content unchanged. The
Filter may return null to indicate
that the FilterHandler should stop processing the
request and should not return any content to the client.
