Re: [jetty-discuss] Re: Any Tutorial about Jetty Sourcecode?

[Niclas H. <ni...@he...>]

On Friday 29 July 2005 03:03, Anthony Cook wrote:
> Niclas Hedhman wrote:

I succumb to sudden-death-by-word-overload ;o)

> Servlet containers, per the specification,
> are extensions of a Web server and ''must support HTTP as a protocol for
> requests and responses''. Per the specification, those requests and
> responses are handled by the servlet, excepting those aspects which are
> not explicitly specified for the container to handle.

Uhhhh.... well, I might be sailing here, but... SRV.1.2. :
"...it may modify requests from the clients before delivering them to the 
servlet, may modify responses produced by servlets before sending them to the 
clients, or may respond to requests without delivering them to the servlet 
under the compliance with RFC2616."

I don't see it fit your description that the container MUST only do what the 
servlet specification explicitly tells it to do.

Looking through the archives about the 100-continue issue earlier, I think 
Greg's insight is remarkable;
<quote src="Greg" >
Ie if a client send the expectation and does not send the body 
until it has a received the 100 response - then 99% of web applications
will fail if run on a jetty that does nothing with this expectation.
</quote>

Although "fail" is a bit strong word, as the RFC2616 says;
<quote src="rfc2616" >
Because of the presence of older implementations, the protocol allows 
ambiguous situations in which a client may send "Expect: 100- continue" 
without receiving either a 417 (Expectation Failed) status or a 100 
(Continue) status. Therefore, when a client sends this header field to an 
origin server (possibly via a proxy) from which it has never seen a 100 
(Continue) status, the client SHOULD NOT wait for an indefinite period before 
sending the request body.
</quote>

It is definately up for interpretation in this case, whether the container 
should handle it or pass it on. My guess is also that the RI has not really 
investigated the case, and by default it falls through.

> ''A reference implementation (RI) has been made available which provides
> a /behavioral benchmark/ for this specification.  Where the
> specification leaves implementation of a particular feature open to
> interpretation, implementors may use the reference implementation /as a
> model of how to carry out the intention of the specification/.'' --
> Servlet Specification 2.4, SRV.P.1, "Additional Sources" [emphasis mine]

Maybe should have emphasize the "may" word as well. 

> > Assuming for a second that Tomcat exposed (for instance, bad classloading 
> > strategy and class is sitting visible in system classloader) some nifty 
> > little util class;
> > 
> >    org.apache.tomcat.util.DoWhatINeed
> >
> > Does that mean all independent implementations must implement/provide
> > that? 

> No, this is an example of /how/ the specification is being implemented
> not /what/ it specifies is to be implemented.

You missed the point; "specification leaves implementation of a particular 
feature open to interpretation" which is just about everything. Does the 
specification mention any casting that can take place? I would assume only 
where casting is required/unavoidable, and all other places is "open to 
interpretation". I am sure given enough time one can define dozens of "open 
to interpretation" where following the RI is not expected or the intent of 
the spec.


>Yet, amusingly enough, when trying to point
> out "specifics" of behaviour within this "technical community", several
> are quick to label me "lawyer-like". :-/

Sorry for giving *your reasoning* such a label. Please note I didn't label you 
"lawyer-like"...  read the fine print ;o)


I conclude (point of stop thinking) that we are at disagreement, and can live 
with that.


Cheers
Niclas