You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by er...@swapsimple.com on 2005/12/18 06:40:36 UTC
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" %>
<c:import url="/testit.txt" var="foo"/>
<%
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: c:import doesn't work right with HEAD requests
Posted by Martin Gainty <mg...@hotmail.com>.
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
<c:import url="file://textit.txt">
Martin-
----- Original Message -----
From: <er...@swapsimple.com>
To: <us...@tomcat.apache.org>
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" %>
> <c:import url="/testit.txt" var="foo"/>
> <%
> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: c:import doesn't work right with HEAD requests
Posted by er...@swapsimple.com.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: c:import doesn't work right with HEAD requests
Posted by Martin Gainty <mg...@hotmail.com>.
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: <er...@swapsimple.com>
To: <us...@tomcat.apache.org>
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" %>
> <c:import url="/testit.txt" var="foo"/>
> <%
> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: c:import doesn't work right with HEAD requests
Posted by er...@swapsimple.com.
On Sun, Dec 18, 2005 at 03:06:19PM +0100, Mikolaj Rydzewski wrote:
> On Sat, 17 Dec 2005 erh@swapsimple.com 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: c:import doesn't work right with HEAD requests
Posted by Mikolaj Rydzewski <mi...@becomo.com>.
On Sat, 17 Dec 2005 erh@swapsimple.com 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: c:import doesn't work right with HEAD requests
Posted by er...@swapsimple.com.
> "Hassan Schroeder" <ha...@webtuitive.com> wrote in message
> news:43A5FC3D.9060204@webtuitive.com...
> > 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: c:import doesn't work right with HEAD requests
Posted by Bill Barker <wb...@wilshire.com>.
"Hassan Schroeder" <ha...@webtuitive.com> wrote in message
news:43A5FC3D.9060204@webtuitive.com...
> erh@swapsimple.com 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 ----------------------------- hassan@webtuitive.com
> Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com
>
> dream. code.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: c:import doesn't work right with HEAD requests
Posted by Hassan Schroeder <ha...@webtuitive.com>.
erh@swapsimple.com 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 ----------------------------- hassan@webtuitive.com
Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com
dream. code.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: c:import doesn't work right with HEAD requests
Posted by er...@swapsimple.com.
On Sun, Dec 18, 2005 at 03:20:09PM -0800, Bill Barker wrote:
>
> <er...@swapsimple.com> wrote in message
> news:20051218224430.GB19379@poe.swapsimple.com...
> > 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: c:import doesn't work right with HEAD requests
Posted by Bill Barker <wb...@wilshire.com>.
<er...@swapsimple.com> wrote in message
news:20051218224430.GB19379@poe.swapsimple.com...
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: c:import doesn't work right with HEAD requests
Posted by er...@swapsimple.com.
On Sun, Dec 18, 2005 at 12:26:07PM -0800, Hassan Schroeder wrote:
> erh@swapsimple.com 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. <snip/>...
>
> 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)
<x:parse xml="${foo} var="xmldoc"/>
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. <snip/>...
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: c:import doesn't work right with HEAD requests
Posted by Hassan Schroeder <ha...@webtuitive.com>.
erh@swapsimple.com 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. <snip/>...
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. <snip/>...
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 ----------------------------- hassan@webtuitive.com
Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com
dream. code.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org