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. <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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
