tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Date Sat, 07 Jan 2006 22:03:37 GMT

"Costin Manolache" <> wrote in message
On 1/7/06, Bill Barker <> wrote:
> Which is exactly what the JSP spec says it should do, and why Remy was
> absolutely correct to consider that this is a users@ question.  It's up to
> the page author to decide how to deal with the request method.
>The page author is us, index.jsp is shipped with tomcat, and so is the
>default servlet.
>My understanding is that the http1.1 spec requires this method to be
>implemented in a particular way - and tomcat code doesn't. Not sure
>what users@ could do about it, except from replacing the default

DefaultServlet inherits doOptions from HttpServlet.  This works correctly 
(and, has back at least to the Sevlet-2.2 days), and is why Servlets rarely 
have to implement it.  If you had index.html instead of index.jsp, you would 
see exactly what you expect to see.

>For JSPs - IMO the JSP spec or our implementation is badly broken in
>this aspect, the fact is that no jsp in existence deals works
>correctly ( according to HTTP spec ).
> I don't thing it matters that this is a problem with the lazy users
>or tomcat developers who forget to implement it. The spec could
>require a default implementation, or require users to implement it if
>running in a http11 server.

It's primarily the JSP spec that is broken.  The few times that I've cared, 
I've used the extends="..." to get the correct HTTP behavior (but 
technically broken JSP spec behavior).  This is about the only solution that 
works (and why it's a users@ issue), since it is impossible for the JSP 
container to determine what methods a JSP Page implements.

I suppose it would be possible to change HttpJspBase.service to call 
super.doOptions if it sees an OPTIONS method instead of what it's supposed 
to do.  The output will be meaningless (if syntactically correct), but so 
would anything else be :).  I'm -0 on this, since IMHO it takes a pretty 
streached reading of the spec to allow it.


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

View raw message