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

[Anthony C. <vs...@mi...>]

Tim Vernum wrote:
> Is your assertion then that Jetty is violating the HTTP spec?
 >

No, not exactly.  One must consider the whole book to get the whole 
story.  My assertion is that something may be implemented out of context.

On that matter, many things have been written to me out of context and I 
have responded by trying to point that out, admittedly, sometimes overly 
critically.  This whole tit-e-tat started that way, by someone 
responding to my own comments and opining on them out of context (and I 
appologize to that individual for responding critically).

I've been told my reasoning is "lawyer-like" because of it (and this 
thread is not the first case among this group) -- because I try to 
interpret parts of the spec in light of the rest of it.  It's been 
suggested I have an inflated sense of self-worth on the subject and that 
I must be either an idiot or just a home hobbyist because my name 
doesn't appear on the committee roster.  Yet, I have 8 years of 
professional experience in servlets, having started with the early 
releases of JServ and the JSDK 2.0.  I imagine someone will start 
hopping up and down and feel the need to reiterate those comments on 
/me/ because of the preceding, though I'm not suggesting my experience 
makes me right, I only offer it to add perspective on those comments...

I've also offered that "intention" and "historical perspective" need be 
considered when interpreting the spec.  So far, no one has offered to 
rebut or even comment on that, though ensuing comments continue to 
discount it as well.

> I can't claim sufficient familiarity with the HTTP spec to have an 
> opinion on that, but if Jetty implements HTTP per the RFC, and the 
> servlet spec defers HTTP issues to the RFC, then surely Jetty is doing 
> the right thing.
> 

There are many "faces" to Jetty and the issue must be considered in the 
context of "which one".  Jetty is an HTTP server and a Servlet 
container.  The servlet spec. says the container must support HTTP, and 
in come instances uses the word "implement".  Yet, again, the two have 
to be considered in context of the whole and that whole is that the 
container is not intended to be a Web server but, rather, /extends/ one. 
  Perhaps we should ask the committee for an errata on what exactly is 
meant by "implement", "support", and "extend" but, then, wouldn't that 
be "nitpicking", especially in light of the whole specification /and/ 
its history?

> Unfortunately the Java specs tend not to define their terms very 
> precisely, so I always assume that they use terms in the same way as the 
> RFCs do,
> 

Yes, indeed.  My comment on use of the word "may" was meant to add 
perspective to my responder's comment that it should be emphasized. 
Though, I also feel emphasizing that aspect of the section takes it out 
of context of its whole self.  In fact, I expected such a response on 
the matter ("emphasize 'may'"), and considered commenting on it in 
advance.  However, in the end I deigned to ignore it and stay focused on 
those aspects which I feel convey the whole intention of the RI.  Yet, 
as expected, the challenge came and I offered a response, of perspective.

> 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is...
> 

While I agree with you in spirit, I feel this too is proposed out of 
context.  RFC2119 defines these words in context of other RFCs using 
them to convey requirement levels of their specified features ("item", 
"option"; the 'what' being specified).  This very section offers plenty 
of evidence that it is referring specifically to inclusion of specified 
"items" or "options" within an implementation.  I don't see that it 
offers a definition of the word to be used in general reading of an RFC 
(or, specification), and in accordance with the following section these 
proffered meanings are to be taken with a grain of salt and considered 
/in context/ of how they are used:

6. Guidance in the use of these Imperatives

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

> Now, the precise context in which the servlet spec authors use "may" 
> doesn't quite fit with the RFC description, but the best guess I can 
> make is that they mean "allowed to, but not required to", which also 
> fits with common usage in my part of the world.
> 

I agree, but offer perspective of context.  The RI is listed as one of 
three sources of interpretive authority and is, contextually, the lowest 
of the three.  So, I see that it makes sense to say that implementors 
"are allowed, but not required" to refer to the RI, when they are 
certainly free to consult the other two sources (assuming the 
implementor even has access to them: 
http://java.sun.com/scholarship/index.html).  Conversely, the mere 
existence of the other two does not imply dismissal of the RI, either.

Before the JCP, the RI served a critical role in compatibility 
certification, but since inception of the JCP (created for political 
reasons, to appease a community lobbying for "more say"; an institution 
which, incidentally, now nominates itself as "final authority", though, 
albeit, for obvious reasons... just a little perspective), many seem 
content to dismiss the RI out of hand and automatically defer directly 
to the committee (or, one of its members). :-/

> which seems to clearly say that issues such as these are *not* resolved 
> by comparing to the RI, but by asking the JCP-WG.
> 

Not resolved /exclusively/ by the RI.  It might also be worth noting 
that, assuming the specification comes out of the JCP-WG, the JCP-WG is 
itself recommending reference to the RI before consulting either the CTS 
or the JCP-WG.

> Also, with respect to
> "how to carry out the intention of the specification"
> to me implies that the RI is useful to understand matters that are 
> covered by the specification, but is not designed to cover matters 
> outside the specification.
> 

Actually, it refers to this in context of ''the specification leav[ing] 
implementation of a particular feature open to interpretation'', which 
implies to me precisely /for/ matters not covered in sufficient detail 
by the specification.

> e.g. Tomcat is started by batch files/shell scripts.
> However I cannot find anything in the spec which says how a servlet 
> container is supposed to be started.
> I think we can all agree that the spec authors do not intend us to 
> consider tomcat's start mechanism to be the prescribed standard.
> 

As do I.  Yet, this is an example of 'how' something is done, not 'what' 
is done in accordance with the spec.  In other words, an example posed 
out of context.

> The question we have here is whether the absence of any mention in the 
> spec about how to handle Expect headers, is intended to define a 
> required behaviour.
 >

Actually, it defers to the HTTP spec for that, which again is a spec for 
Web servers, of which servlet containers are an "extension".  My point 
on the matter is not that the spec defines a required behaviour with 
regard to the header (which I've stated is not the servlet spec's 
purpose: to define general handling of HTTP).  My point is that the 
spec. defines specific behaviours with regard to /specific/ headers, or 
HTTP attributes, and beyond those the servlet writer is left to decide. 
  In my opinion, over /8 years/ of servlet specification and API 
documentation has stated or implied this rather clearly.  Though, 
despite that, I've recently been told that the servlet writer has "NO 
mechanism" for making those decisions (and that from one of the 
committee members). :-/

As to the intent and purpose of this particular header, I've already 
opined at length (though, as I've been told, not "clearly" enough).

> It seems you believe that to be the case, and therefore the 
> implementation in the RI can be used as a model of their intentions.
 >

I believe that's what the specification itself is saying, and I agree 
with it.  Though, hopefully I've cast more light on the context in which 
I agree.

> But if in fact it is missing from the spec because the working group did 
> not ever consider it, then the RI is not a model of the "intention of 
> the specification", as there is no intention to be modeled.
> 

Ok.  Another way of looking at it is that the specification /describes/ 
behaviours, or "intentions", and the RI provides a model for viewing 
them.  With this in mind, again, the specification describes 'what', not 
'how', and the "model" for which the RI is offered pertains /only to/ 
those things specified.  Everything else falls outside the scope of 
'what' and falls squarely into 'how', which is beyond the spec.

> I think the spec authors do themselves a disservice by implying that all 
> of the behaviour in the RI is intentional, when we all know that all 
> pieces of software have unintentional features/non-features.
> 

Perhaps they are.  Or, perhaps, we do ourselves a disservice by assuming 
this to be the case, "missing the forest for the trees" so to speak.

> I don't think it is fair to claim that Jetty is non-complaint. The spec 
 >

I mis-spoke on this point.

> clearly states that in situations such as these clarification should 
> come from the working group. So, in absence of such a clarification, I 
> can't see that it is possible to claim anything about how a compliant 
> container should handle the Expect header.
> 

On the contrary, I've been saying that it /shouldn't/ handle it.  A 
point I make in light of what else I've been saying, that the spec. says 
/explicitly/ what the container handles, and leaves the rest to the servlet.

Regards