Cedric,

The servlet container automatically handles head requests by calling doGet
but then only returns the headers.  This can be very inefficient in cases
such as yours.

The O'Reilly "Java Servlet Programming" book suggests at the top of doGet()
do:
request.setContentType(<correctContentTypeForThisRequest>);
if (request.getMothod().equals("HEAD")) return;

I've never tried this though.

Andy

> -----Original Message-----
> From: Cédric Viaud [mailto:[EMAIL PROTECTED]]
> Sent: 27 November 2002 13:31
> To: Tomcat Users List
> Subject: Re: Pb with HEAD request
>
>
> Hi Kristján,
>
> in fact, i've first check the RFC of HTTP 1.1 (see after the mail what it
> says about HEAD command). So i've look to the servlet specification .And
> haven't seen the "doHead" method.
>
> Next to your reply , i've checked again, and discover that i MISSED it :-(
>
> So i've coded the "doHead" method , but it never seems to be called by my
> servlet. I can't manage to know if this is a client or a server issue.
>
> Anyone gets an idea. ?
>
> Anynyway, i think i will have to implement a cache , because some
> of my Get
> actions need many calculation, and doing this twice for the same request
> will decrease the application performance.
>
> Thanks for help, regards,
>
>    Cédric
>
>
> ------------------------------------------------------------------
> ----------
> ----
> From RFC 2616 about HTTP 1.1
>
> "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.
> This method is often used for testing
> hypertext links for validity, accessibility, and recent modification.
> The response to a HEAD request MAY be cacheable in the sense that the
> information contained in the response MAY
> be used to update a previously cached entity from that resource.
> If the new
> field values indicate that the cached entity
> differs from the current entity (as would be indicated by a change in
> Content-Length, Content-MD5, ETag
> or Last-Modified), then the cache MUST treat the cache entry as stale."
>
>
>
> ----- Original Message -----
> From: "Kristján Bjarni Guđmundsson" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Tuesday, November 26, 2002 4:40 PM
> Subject: Re: Pb with HEAD request
>
>
> You really should look into the servlet specification.
> I think if you override doHead for your servlet
>
> doHead(HttpServletRequest req, HttpServletResponse resp)
>
> Receives an HTTP HEAD request from the protected service method and
> handles the request.
>
> Default action for doHead is to simply call doGet
>
> Cédric Viaud <[EMAIL PROTECTED]> wrote on 26.11.2002 15:32:45:
>
> > Hi,
>
> > I have Tomcat server 4.0.4 on NT 4 that contains a servlets in
> > charge to create SVG content.
>
> > The client is Internet Explorer 5.5. It loads the following simple HTML
> page :
>
> > <html>
> > <body>
> > <embed width="200" height="200"
> src="http://localhost:8080/myContext/MyServlet
> > >
> > </body>
> > </html>
>
> > The problem is that my servlet is invoked twice.
>
> > My supposition is that IE is sending a HEAD (or GET) request to know
> > the content type of the URL and then run the Adobe SVG plugin. When
> > started the plugin connects also the servlet to get SVG content.
> > HTTP spec says that HEAD request must return the same headers as GET
> > request. What is sure is that my code is executed twice, not only
> > the part that concerns response headers. But how can I do to know
> > with the servlet if the request is a GET or a HEAD. I test the
> > HttpRequest.getMethod() but it always return "GET".
>
> > Does someone know how to "configure" tomcat or anything else to
> > avoid the two executions ?
>
> > Thanks.
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to