On 1/7/06, Bill Barker <[EMAIL PROTECTED]> wrote: > 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.
You're right, I forgot about the base class. Yes, it does getDeclaredMethods - so works for all servlets that use doGet, doPost, etc. I was looking for something specific in DefaultServlet. > >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. What about returning just GET, HEAD as supported method for Jsps that don't override this ? Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
