Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of jak-tomcat-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@tomcat.apache.org
From: "Bill Barker" <wbarker@wilshire.com>
Subject: Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Date: Sat, 7 Jan 2006 14:03:37 -0800
Lines: 49
Message-ID: <dppdqn$r29$1@sea.gmane.org>
References: <43BE636F.7040807@jmatica.com>
 <96e4b5230601060950r3c93a395r4823c94412bef2c8@mail.gmail.com>
 <43BEBA0E.9030303@jmatica.com>
 <96e4b5230601061217n6f4c2a0ftf6366142be935c4a@mail.gmail.com>
 <43BED2BE.4010307@Apache.org>
 <96e4b5230601061257k55e3ddacw8555f8be8799e584@mail.gmail.com>
 <43BEE038.3080104@jmatica.com> <43BF9EFA.9010208@apache.org>
 <43BFA402.2050007@apache.org> <dpp5fr$15n$1@sea.gmane.org>
 <96e4b5230601071306r100db033p775d606d5a97d225@mail.gmail.com>
Sender: news <news@sea.gmane.org>


"Costin Manolache" <costin@gmail.com> wrote in message 
news:96e4b5230601071306r100db033p775d606d5a97d225@mail.gmail.com...
On 1/7/06, Bill Barker <wbarker@wilshire.com> 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
>servlet.

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.


>
>Costin
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org