"Costin Manolache" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On 1/7/06, Bill Barker <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
