[5.0] Needed Servlet API clarifications

[Remy Maucherat <re...@apache.org>]

Hi,

There are some points that, IMO, could use some clarification in the 
specifications.

* Invocation of FORM login and error pages. This can legally be 
implemented in the following ways (according to my understanding of the 
specification; let me know if I am wrong):
   - redirect: Send a HTTP redirect. A new request will be sent, and as 
a result, this is equivalent to making a direct request to the login 
page, as far as filters are concerned. This is inherently slow, and what 
we've been using for TC 4.x.
   - forward: Invacation using a forward. One of the problems IMO is 
that this is not done inside the servlet API pipeline, which breaks the 
semantics (and in the current 5.0.x implementation breaks the 
processing). Filters mapped as FORWARD will be invoked, but the normal 
filter pipeline will never be invoked (which IMO is not right).
   - rewrite: Mutate the request, map it to a servlet, and directly 
invoke it. We could also invoke the normal filter pipeline. This seems 
to be the "good" solution.

Anyway, the spec needs to choose between the three (or four) solutions, 
as they don't have the same behavior with respect to filter invocation.

* Wrapping in the request dispatcher. The spec says that req/resp 
wrappin gis not mandatory if the container provided objects are passed 
to the dispatcher. In practice, however, wrapping always occur to 
maintain the required isolation for the parameters (but this could be 
done without wrapping), and a hypothetic need for request attributes 
isolation (I couldn't find where this is specified !!!).

So the specification should say if request attributes isolation is 
needed. If it's not, we could avoid wrapping and optimize more. If 
wrapping is mandatory because of request attributes, there are only a 
few more optimizations which can be introduced.

As a side note, the spec says you must wrap if the request/response is a 
wrapper, and that does include the container provided wrappers.

* Filtering. Filtering is not very efficient nowdays, because of the 
need to wrap to be able to modify the request, for even the most basic 
operations. Wrapping in the filters also introduces mandatory rewrapping 
if the request dispatcher is invoked. Catalina-like mutators and 
accessors could be introduced on the Request/Response interfaces.

Remy



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

How do I reroute my EMAIL in this forum

[Jerry Birchler <jr...@attbi.com>]

My cable provider is putting me through an email conversion process that
worries me. In response, I have created my own email server and have been
using that email address. I want to switch from my old to this one. Is there
an easy way to do it as a subscription process?

Thanks


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org