tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: two responses from one request - how is it possible ?
Date Tue, 23 Apr 2013 15:53:38 GMT
Jeffrey Janner wrote:
>> -----Original Message-----
>> From: André Warnier []
>> Sent: Monday, April 22, 2013 4:40 PM
>> To: Tomcat Users List
>> Subject: Re: two responses from one request - how is it possible ?
>> Jeffrey Janner wrote:
>> ...
>>> In actuality, he should have stopped the first sentence at "Engine",
>> and then continued with a new sentence (keeping in mind the simplified
>> structure):
>>>   "The Engine will then see if the first string after the hostname
>> portion
>>>    of the request URL matches any of the defined contexts. If a match
>> is found,
>>>    then the request is passed to that context and the response is
>> sent back
>>>    via the original connector.  If a match is not found, then an
>> error is returned."
>> That is a big improvement over the original (which in my view is quite
>> beyond redemption), but I believe that a better way would be to point
>> the interested reader to chapter 12 of the Java Servlet Specification
>> 3.0 ("Mapping Requests to Servlets"), which says it all (granted, in
>> many more words).
>> What is for example missing above are the concepts of, and mapping to,
>> the "default context", servlets within a context, and "default
>> servlet".
> Well, I was going to actually go into that depth, but decided to limit myself to their
specific example.
> I had thought of explaining how the engine picks the host, and the host picks the context,
and the context picks the servlet, then thought I'd limit myself as they had limited themselves.
> They only specified a single <Host> element with all default values, so I stuck
to that example.
Well, I did not want Jakub to remain influenced by that very bad page, so I started along

the same path as you did, and after writing half a page and getting into the details of 
how Tomcat matched the second and next components of the URL path to the <url-mapping>

elements of the selected context's web.xml, possibly ending up defaulting to the default 
servlet, which itself is defined in the default web.xml..
I decided that it was easier - and less prone to get a rebuff myself from Pid or so - to 
point to the servlet spec.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message