On Mon, 29 Jul 2002 noreply_at_sourceforge.net wrote:

> https://sourceforge.net/tracker/?func=detail&atid=100976&aid=588027&group_id=976

> This bug is related to using libcurl with Tomcat and jsp pages. In the
> default configuration Tomcat handles properly HEAD request for files,
> however it returns the whole body when doing a HEAD on jsp files -- the
> Tomcat HEAD handler is probably just calling the GET handler.
>
> When using persistent connections and mixing HEAD and GET commands libcurl
> may read the (wrongly sent) body of a HEAD command as the header of the
> GET command.

This troubles me a bit. In fact, I've tried to think of various ways of how
to approach this problem but I fail to get a good answer no matter how I
turn...

First let's make things clear, the RFC2616 states: "The HEAD method is
identical to GET except that the server MUST NOT return a message-body in the
response.

curl adheres to this and stops reading as soon as the last header has been
received. Now, some servers obviously return a response *anyway*. This makes
curl confused when it re-uses the connection to do a subsequent request, as
it then mistakes the previous response with the expected new response.

What can we do about this? As I can see it, there are only a few existing
possibilities:

1) Read out the response. This can't be done properly, as the
   'Content-Length' reported is for the resource when we use GET, not HEAD,
   so we can't know how much to read. We thus have to read until socket is
   closed, which will cause it to hang on a timeout on the server...

2) Fail miserably on servers that abuse the RFC (current situation). I don't
   like this.

3) Try to detect this situation and adjust accordingly. Can this be done? I
   would need detailed header dumps from Tomcat servers that do like this
   first to tell. I'm not very optimistic about this, as I can't figure out a
   to even wish for to detect this. Of course, if they say Connection: close
   in the header we could close it immediately, but then we would already
   have done so and this wouldn't have been a problem.

4) Close connectons after HEAD requests. While this would fix this particular
   case, it would also cause a sever performance blow and I don't like the
   idea of making 99.9% of all requests worse, only to make the 0.1% case
   work better (that even violates the protocol).

Please, I need input and guidance here!

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31