Re: c:import doesn't work right with HEAD requests
Good Morning Eric- Did you include the core taglib spec before using 'c' reference identifier <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %> What does the Tomcat log say about this? HTH, Martin- - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Sunday, December 18, 2005 12:40 AM Subject: c:import doesn't work right with HEAD requests > > I'm having some trouble getting the c:import tag to work right. > It seems to be perfectly fine when the request that tomcat receives is > a GET request. However, when it receives a HEAD request instead, c:import > never actually reads the data. > Is this a known bug? Is it fixed in a more recent version of tomcat? > I'm using 5.0.30. > > eric > > Here's an example jsp file testit.jsp: > ---cut--- > <%@ taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c" %> > > <% >System.out.println("FOO:[" + pageContext.getAttribute("foo") + "]"); > %> > worked: ${foo} > ---cut--- > > Here's testit.txt: > ---cut--- > data data data > ---cut--- > > When I send a GET request to retrieve /myapp/testit.jsp, I get the expected > "worked: data data data" in the response, and in catalina.out I get: > ---cut--- > FOO:[data data data > ] > ---cut--- > That's what I expect. However, if I send a HEAD request I get no output > other than headers in the response (as I expect), but catalina.out has > this instead: > ---cut--- > FOO:[] > ---cut--- > Notice there's nothing inside the []. > > Here's my HEAD request transcript: > > poe: {50} telnet localhost 8080 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > HEAD /myapp/testit.jsp HTTP/1.1 > Host: localhost:8080 > > HTTP/1.1 200 OK > Set-Cookie: JSESSIONID=5A2DA89DDC03A24F4CF110EFD1BB6541; Path=/myapp > Content-Type: text/html;charset=ISO-8859-1 > Content-Length: 15 > Date: Sun, 18 Dec 2005 05:29:54 GMT > Server: Apache-Coyote/1.1 > > ^] > telnet> c > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: c:import doesn't work right with HEAD requests
On Sat, 17 Dec 2005 [EMAIL PROTECTED] wrote: > I'm having some trouble getting the c:import tag to work right. > It seems to be perfectly fine when the request that tomcat receives is > a GET request. However, when it receives a HEAD request instead, c:import > never actually reads the data. > Is this a known bug? Is it fixed in a more recent version of tomcat? > I'm using 5.0.30. Are you sure, that container should 'run' jsp page with head request? -- Mikolaj Rydzewski Becomo SA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
On Sun, Dec 18, 2005 at 09:06:22AM -0500, Martin Gainty wrote: > Did you include the core taglib spec before using 'c' reference identifier > <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"; %> Of course. It's the very first line in testit.jsp. w/o that it wouldn't work even for GET requests. > What does the Tomcat log say about this? The only output in the log is what I wrote there with System.out.println. eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
Eric- the examples dont indicate how the leading slash can work without the URL specification (in this case URL spec for file) did you try Martin- - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Sunday, December 18, 2005 12:40 AM Subject: c:import doesn't work right with HEAD requests > > I'm having some trouble getting the c:import tag to work right. > It seems to be perfectly fine when the request that tomcat receives is > a GET request. However, when it receives a HEAD request instead, c:import > never actually reads the data. > Is this a known bug? Is it fixed in a more recent version of tomcat? > I'm using 5.0.30. > > eric > > Here's an example jsp file testit.jsp: > ---cut--- > <%@ taglib uri="http://java.sun.com/jsp/jstl/core"; prefix="c" %> > > <% >System.out.println("FOO:[" + pageContext.getAttribute("foo") + "]"); > %> > worked: ${foo} > ---cut--- > > Here's testit.txt: > ---cut--- > data data data > ---cut--- > > When I send a GET request to retrieve /myapp/testit.jsp, I get the expected > "worked: data data data" in the response, and in catalina.out I get: > ---cut--- > FOO:[data data data > ] > ---cut--- > That's what I expect. However, if I send a HEAD request I get no output > other than headers in the response (as I expect), but catalina.out has > this instead: > ---cut--- > FOO:[] > ---cut--- > Notice there's nothing inside the []. > > Here's my HEAD request transcript: > > poe: {50} telnet localhost 8080 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > HEAD /myapp/testit.jsp HTTP/1.1 > Host: localhost:8080 > > HTTP/1.1 200 OK > Set-Cookie: JSESSIONID=5A2DA89DDC03A24F4CF110EFD1BB6541; Path=/myapp > Content-Type: text/html;charset=ISO-8859-1 > Content-Length: 15 > Date: Sun, 18 Dec 2005 05:29:54 GMT > Server: Apache-Coyote/1.1 > > ^] > telnet> c > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: c:import doesn't work right with HEAD requests
[EMAIL PROTECTED] wrote: > I'm having some trouble getting the c:import tag to work right. > It seems to be perfectly fine when the request that tomcat receives is > a GET request. However, when it receives a HEAD request instead, c:import > never actually reads the data. > System.out.println("FOO:[" + pageContext.getAttribute("foo") + "]"); Logically, why would you expect a pageContext to be created in the absence of a request for a "page"? :-) However, from the Servlet Spec -- protected void doHead(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException Receives an HTTP HEAD request from the protected service method and handles the request. The client sends a HEAD request when it wants to see only the headers of a response, such as Content-Type or Content-Length. The HTTP HEAD method counts the output bytes in the response to set the Content-Length header accurately. If you override this method, you can avoid computing the response body and just set the response headers directly to improve performance. ... So it sounds like Tomcat's doHead() is doing exactly that. Which means the Content-Length value supplied (test: TC 5.5.9) is different for a GET vs. HEAD request in your scenario. Which sounds bad to me, but the HTTP 1.1 spec says -- 9.4 HEAD The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. ... I'd think the SHOULD above would be a MUST, but since it's not, it's apparently "legal", if (IMHO) ill-advised, to return different values of Content-Length for HEAD and GET requests for the same object. Trying a similar test with Apache httpd (2.0.52), though, results in *no* Content-Length returned from a HEAD request for a page with a dynamic include component, while HEAD/GET requests for a static page each return the same Content-Length value. So is the Tomcat behavior a bug? I'd at least call it undesirable, but the easiest and most performant fix would be for doHead() to not return Content-Length at all; the more-useful-but-slower approach would be to build the page/count bytes/discard and I'm not sure I'd want to see that... Perhaps someone else will have an opinion :-) -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
On Sun, Dec 18, 2005 at 03:06:19PM +0100, Mikolaj Rydzewski wrote: > On Sat, 17 Dec 2005 [EMAIL PROTECTED] wrote: > > > I'm having some trouble getting the c:import tag to work right. > > It seems to be perfectly fine when the request that tomcat receives is > > a GET request. However, when it receives a HEAD request instead, c:import > > never actually reads the data. > > Is this a known bug? Is it fixed in a more recent version of tomcat? > > I'm using 5.0.30. > > Are you sure, that container should 'run' jsp page with head request? no, I believe the container can decide not to run it. But tomcat IS running the page, as can be seen from the output in the logs. If the jsp page didn't run at all, there would be no output in the log. The problem is that it is running it _differently_ when a HEAD request is received. eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
On Sun, Dec 18, 2005 at 12:26:07PM -0800, Hassan Schroeder wrote: > [EMAIL PROTECTED] wrote: > However, from the Servlet Spec -- > protected void doHead(HttpServletRequest req, > HttpServletResponse resp) > throws ServletException, IOException > Receives an HTTP HEAD request from the protected service method > and handles the request. The client sends a HEAD request when it > wants to see only the headers of a response, such as Content-Type > or Content-Length. The HTTP HEAD method counts the output bytes > in the response to set the Content-Length header accurately. > > If you override this method, you can avoid computing the response > body and just set the response headers directly to improve > performance. ... > > So it sounds like Tomcat's doHead() is doing exactly that. Which means > the Content-Length value supplied (test: TC 5.5.9) is different for a > GET vs. HEAD request in your scenario. Which sounds bad to me, but the > HTTP 1.1 spec says -- I really couldn't care less whether the content-length header is different. The important thing here is what is in the logs. When you tested it, do you get a "FOO:[...]" line in your logs (that corresponds to the HEAD request)? Does it have something between the '[' and ']'? The problem is that I _am_ getting a line like that, which implies that tomcat runs the jsp page, but there is nothing between the brackets. You can't see in the test case that I sent, but this causes all sorts of problems if you have code that tries to use the data that c:import supposedly loads. Perhaps I simplied the test case a bit too much. The original case where I saw this problem was actually this: - c:import is used to load an xml file - x:parse is used to parse the xml file. e.g. add this after the c:import: (with appropriate taglib line too) and make testit.txt contain xml data. The url used in c:import is a local url to a static xml file, so I have code that assumes the file will be there and that it will parse successfully. This is a reasonable assumuption since I don't expect files in my web app directory to change or disappear unless I reinstall the webapp. When a HEAD request is done, the c:import behaves as if the xml file is empty, which then causes an exception in x:parse, which results in a internal server error response. >9.4 HEAD > >The HEAD method is identical to GET except that the server MUST NOT >return a message-body in the response. The metainformation contained >in the HTTP headers in response to a HEAD request SHOULD be identical >to the information sent in response to a GET request. This method can >be used for obtaining metainformation about the entity implied by the >request without transferring the entity-body itself. ... > I'd think the SHOULD above would be a MUST, but since it's not, it's > apparently "legal", if (IMHO) ill-advised, to return different values > of Content-Length for HEAD and GET requests for the same object. Since this says "SHOULD be identical", it seems reasonable to expect that things like content-length will be different (or omitted). However, I doubt this was meant to imply that a "500 Internal Server Error" response is valid for a url that would work with a GET request. > Trying a similar test with Apache httpd (2.0.52), though, results in > *no* Content-Length returned from a HEAD request for a page with a > dynamic include component, while HEAD/GET requests for a static page > each return the same Content-Length value. but, it returns a 200-level success response, not an error, right? My guess is that tomcat uses a "HEAD" request to retrieve content with c:import if the request for the jsp page containing the c:import was requested with a "HEAD" request. I'm not familiar enough with the tomcat code to easily figure out whether this is actually the case or not. If that's really what's happening, then I think it's wrong. When a HEAD request is received, the jsp page should either: 1) run exactly the same as if a GET request was received 1a) unless the jsp page _explicitly_ checks the request method with ${request.method} or equivalent. 2) not run at all eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Sun, Dec 18, 2005 at 12:26:07PM -0800, Hassan Schroeder wrote: > My guess is that tomcat uses a "HEAD" request to retrieve content with > c:import if the request for the jsp page containing the c:import was > requested with a "HEAD" request. I'm not familiar enough with the tomcat > code to easily figure out whether this is actually the case or not. Actually, it JSTL rather than Tomcat, but you're basically correct, that is what is happening. It could be fixed in c:import (to wrap the Request, and report GET for HEAD), but that is outside of Tomcat. > If that's really what's happening, then I think it's wrong. When a HEAD > request is received, the jsp page should either: > 1) run exactly the same as if a GET request was received This is outside of Tomcat's control, since any Servlet is free to override doHead to do anything it wants ;-). In fact, this is one work-around for your problem: Use extends="com.myfirm.mypackage.MyJSPPage", and implement doHead there. > 1a) unless the jsp page _explicitly_ checks the request method > with ${request.method} or equivalent. Checking this is probably the easiest work-around. It's very unlikely that Tomcat could do it relyably. > 2) not run at all > That would violate the spec. > eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
[EMAIL PROTECTED] wrote: > I really couldn't care less whether the content-length header is > different. The important thing here is what is in the logs. No, it's not; the important thing is whether there's any applicable spec that (even indirectly) requires the container to generate the exact same response body (to be discarded rather than returned) for a HEAD request as for a GET. > When you tested it, do you get a "FOO:[...]" line in your logs (that > corresponds to the HEAD request)? > Does it have something between the '[' and ']'? No. But I wouldn't have *any* expectations of an ambiguous situation. Out of curiousity, have you tried this with any different containers (Jetty, Resin, JRun, ...)? > The problem is that I _am_ getting a line like that, which implies > that tomcat runs the jsp page, but there is nothing between the brackets. > You can't see in the test case that I sent, but this causes all sorts of > problems if you have code that tries to use the data that c:import > supposedly loads. It sounds like a problem to develop an app based on behavior that's not required by any spec (or handled totally by your own code). :-) FWIW! -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
"Hassan Schroeder" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [EMAIL PROTECTED] wrote: > >> I really couldn't care less whether the content-length header is >> different. The important thing here is what is in the logs. > > No, it's not; the important thing is whether there's any applicable > spec that (even indirectly) requires the container to generate the > exact same response body (to be discarded rather than returned) for > a HEAD request as for a GET. > The Servlet spec and the HTTP/1.1 RFC have a slight disagreement here: For a Servlet that doesn't implement doHead, and doesn't set contentLength in it's doGet method, a HEAD request will send back a 'Content-Length' header and no 'Transfer-Encoding' header. A GET request (unless the content is very small, at least on Tomcat) will send back no 'Content-Length' header, and a 'Transfer-Encoding: chunked' header. >> When you tested it, do you get a "FOO:[...]" line in your logs (that >> corresponds to the HEAD request)? >> Does it have something between the '[' and ']'? > > No. But I wouldn't have *any* expectations of an ambiguous situation. > Out of curiousity, have you tried this with any different containers > (Jetty, Resin, JRun, ...)? > >From http://issues.apache.org/bugzilla/show_bug.cgi?id=37466, it looks like it's a waste of time checking other containers. It seems that this is a known bug at least in the Jakarta implementation of JSTL. >> The problem is that I _am_ getting a line like that, which implies >> that tomcat runs the jsp page, but there is nothing between the brackets. >> You can't see in the test case that I sent, but this causes all sorts of >> problems if you have code that tries to use the data that c:import >> supposedly loads. > > It sounds like a problem to develop an app based on behavior that's > not required by any spec (or handled totally by your own code). :-) > > FWIW! > -- > Hassan Schroeder - [EMAIL PROTECTED] > Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com > > dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
On Sun, Dec 18, 2005 at 03:20:09PM -0800, Bill Barker wrote: > > <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > My guess is that tomcat uses a "HEAD" request to retrieve content with > > c:import if the request for the jsp page containing the c:import was > > requested with a "HEAD" request. I'm not familiar enough with the tomcat > > code to easily figure out whether this is actually the case or not. > > Actually, it JSTL rather than Tomcat, but you're basically correct, that is > what is happening. It could be fixed in c:import (to wrap the Request, and > report GET for HEAD), but that is outside of Tomcat. I feared that might be the case. I asked on the apache taglibs list, but that list is rather empty of people, so I got no response. :( > > If that's really what's happening, then I think it's wrong. When a HEAD > > request is received, the jsp page should either: > > 1) run exactly the same as if a GET request was received > > This is outside of Tomcat's control, since any Servlet is free to override > doHead to do anything it wants ;-). In fact, this is one work-around for > your problem: Use extends="com.myfirm.mypackage.MyJSPPage", and implement > doHead there. yuck. That seems like gross solution. > > 1a) unless the jsp page _explicitly_ checks the request method > > with ${request.method} or equivalent. > > Checking this is probably the easiest work-around. It's very unlikely that > Tomcat could do it relyably. ah, oh well. I guess I'll do something like this. Thanks. eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
> "Hassan Schroeder" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > No. But I wouldn't have *any* expectations of an ambiguous situation. > > Out of curiousity, have you tried this with any different containers > > (Jetty, Resin, JRun, ...)? no, I haven't. I think I've got a websphere instance I can get to. I'll try it there. That might have a different implementation of the core taglibs even . On Sun, Dec 18, 2005 at 05:08:54PM -0800, Bill Barker wrote: > >From http://issues.apache.org/bugzilla/show_bug.cgi?id=37466, it looks like > it's a waste of time checking other containers. It seems that this is a > known bug at least in the Jakarta implementation of JSTL. known? ha! I submitted that, and judging by the response I got when asking about this problem on the taglibs list, I wouldn't be surprised if you're the first other person to see that bug. :-| eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: c:import doesn't work right with HEAD requests --> Ref #[1M8EmBBCnE0fSre]
Hello, Thank you for contacting Juno. This is an automated response sent to email messages suspected to be spam by our spam filters. This process will help us filter spam messages and respond to genuine customer concerns quickly. We apologize if your email is mistakenly identified as spam. Please reply to this message and one of our support agents will get back to you. Sincerely, Juno Customer Care - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]