"Carlin Rogers" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Tomcat Users,
>
> I was wondering if anyone knows of documentation or forum discussions
> around
> areas of the Java Sevlet Spec that Tomcat does not support. I noticed that
> the Tomcat implementation for HttpServletRequest getContextPath() returns
> a
> decoded string. The 2.3 and 2.4 spec and the API documentation state that
> "the container does not decode this string." As an application programmer,
> it is difficult to determine the best way to handle different behavior
> across containers when they do not conform to the spec. Anyway, I decided
> to
> log a bug on Tomcat. See...
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39503
>
> I was a little surprised by the response and the fact that development
> didn't seem too interested in the issue...
>
> "First of all, let me state that I don't care at all about the
> nonsensical things
> the specification says, and which has slipped in for whatever unintended
> reason.
> I will let you reopen the report if you wish to, but will ignore it
> completely,
> and let me assure you this will never get fixed."
>
Probably true. It adds way too much complexity to the code, for very little
gain. As a simple example, consider:
GET /my%20app%2fmy%20servlet%2fmy%20path%20info HTTP/1.1
> It's not a big deal, and I'll live with the decision but I was curious if
> there were posts or information about the process to determine what parts
> of
> the spec were not essential or just not clear.
Pretty much all of them have been discussed at length on [EMAIL PROTECTED]
and/or
BZ. The archives are your friend :).
>
> Is there information on any other areas of the spec that Tomcat has chosen
> not to implement or conform to? Granted, the spec is not always clear and
> there's room for interpretation, but it would be nice to know in advance
> where one might see divergence in containers. Thanks for any info.
>
Off the top of my head:
1) Extension-mapped welcome-pages -- Tomcat requires a physical resource to
be present to use it.
2) Flush after a forward -- The following doesn't work as expected:
try {
rd.forward(request, response);
} finally {
doSomeLongAndComplexDbUpdate(request, response);
}
3) Tomcat catches most cases, but doesn't strictly enforce that the
Request/Response passed to an include/forward *must* be either the original
Request/Response, or a Request/ResponseWrapper that wraps the orignal
Request/Response.
> Kind regards,
> Carlin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
