this is a similar thread - see if helps at all:
http://marc.theaimsgroup.com/?l=tomcat-user&w=2&r=1&s=filters+running+twice&;
q=b

Charlie

> -----Original Message-----
> From: Cédric Viaud [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 27, 2002 8:31 AM
> 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