Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Costin Manolache wrote: I'm curious - why would you need the options method ? Obviously, as you found, tomcat does not support it ( and many other servers ), and I never heard of any use of it, even if it is in the spec. Well, in theory servlets could respond to 'options' method if they choose to - and so could the default servlet. Whoa!!! Most clients rely on this to determine if, for example, the server supports DAV. OPTIONS absolutely must be supported, per spec, and it's absense breaks, for example, some of the download managers which will use DAV retrieval using PROPGET of a given document when available, and simple GET when not. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
William A. Rowe, Jr. wrote: > Costin Manolache wrote: > >> I'm curious - why would you need the options method ? >> >> Obviously, as you found, tomcat does not support it ( and many other >> servers ), and I never heard of any use of it, even if it is in the >> spec. >> >> Well, in theory servlets could respond to 'options' method if they >> choose to - and so could the default servlet. > > > Whoa!!! Most clients rely on this to determine if, for example, the > server supports DAV. OPTIONS absolutely must be supported, per spec, > and it's absense breaks, for example, some of the download managers > which will use DAV retrieval using PROPGET of a given document when > available, and simple GET when not. Options is supported in javax.servlet.http.HttpServlet org.apache.catalina.servlets.DefaultServlet does not override this. org.apache.catalina.servlets.WebdavServlet does override it to set the DAV, Allow and MS-Author-Via headers. >From a WEBDAV point of view, everything looks fine. The response to static resources is a different question which I will respond to separately. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Mauro Bertapelle wrote: > Costin, > > you've got the point I was trying to make, this has nothing to do with > webdav and the naive > way in which ie implements it, but probably Tomcat should handle > "options" better when > it's acting as a static web server. > > Mauro I have confirmed this behaviour with the latest source from SVN. It is a bug. I'll look into it. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Mark Thomas wrote: > Mauro Bertapelle wrote: >>this has nothing to do with >>webdav and the naive >>way in which ie implements it, but probably Tomcat should handle >>"options" better when >>it's acting as a static web server. >> >>Mauro > > I have confirmed this behaviour with the latest source from SVN. It is > a bug. I'll look into it. > It is as a result Jasper. A request for: OPTIONS http://localhost:8080/ HTTP/1.1 or OPTIONS http://localhost:8080/index.jsp HTTP/1.1 eventually calls the _jspService method created by Jasper in org.apache.jasper.compiler.Generate.generatePreamble() which assumes a request method of GET. I have commitments which mean I will not be able to look at this for a day or two at the earliest. If no one else fixes it between now and early next week, I'll look at it then. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
DefaultServlet doesn't implement OPTIONS either, and I don't remember ever implementing or seeing an implementation of the method in anything except webdav servlet. Since it is part of the standard - and it seems it is even used - we should support it, but this has been broken forever. I'm curious if it could be implemented at container level, maybe detecting if a servlet doesn't implement it and returning a default implemenation ? Tomcat can detect what methods are implemented - unless the servlet overrides service(). Costin On 1/7/06, Mark Thomas <[EMAIL PROTECTED]> wrote: > Mark Thomas wrote: > > Mauro Bertapelle wrote: > >>this has nothing to do with > >>webdav and the naive > >>way in which ie implements it, but probably Tomcat should handle > >>"options" better when > >>it's acting as a static web server. > >> > >>Mauro > > > > I have confirmed this behaviour with the latest source from SVN. It is > > a bug. I'll look into it. > > > > It is as a result Jasper. A request for: > OPTIONS http://localhost:8080/ HTTP/1.1 > > or > OPTIONS http://localhost:8080/index.jsp HTTP/1.1 > > eventually calls the _jspService method created by Jasper in > org.apache.jasper.compiler.Generate.generatePreamble() which assumes a > request method of GET. > > I have commitments which mean I will not be able to look at this for a > day or two at the earliest. If no one else fixes it between now and > early next week, I'll look at it then. > > Mark > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
"Mark Thomas" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Mark Thomas wrote: >> Mauro Bertapelle wrote: >>>this has nothing to do with >>>webdav and the naive >>>way in which ie implements it, but probably Tomcat should handle >>>"options" better when >>>it's acting as a static web server. >>> >>>Mauro >> >> I have confirmed this behaviour with the latest source from SVN. It is >> a bug. I'll look into it. >> > > It is as a result Jasper. A request for: > OPTIONS http://localhost:8080/ HTTP/1.1 > > or > OPTIONS http://localhost:8080/index.jsp HTTP/1.1 > > eventually calls the _jspService method created by Jasper in > org.apache.jasper.compiler.Generate.generatePreamble() which assumes a > request method of GET. > 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. > I have commitments which mean I will not be able to look at this for a > day or two at the earliest. If no one else fixes it between now and > early next week, I'll look at it then. > > Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
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. 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. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
"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]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
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]
