On Tue, 23 Jul 2002, Marius Seritan wrote:

(I changed this post to go to the libcurl mailing list instead of curl-users
that it was posted to in the first place.)

> As usually, it just takes one bug report to the world before you can leap
> ahead on your bug resolution :-(
>
> I was able to duplicate the problem reported below issue with logging on
> and it is related to a clash between 2 successive transfers on the http/1.1
> persistent socket. The big problem (in the app and/or tomcat level) is that
> tomcat replies with a header AND a body to a HEAD request :-( After this
> mishap tomcat closes the socket, however curl may already be started on the
> next http POST. Curl will interpret the body of the previous HEAD as a post
> and hang.
>
> 1. curl sends the headerer for the HEAD
> 2. tomcat replies with the HEAD header
> 3. curl returns to the app

Thanks for your detailed report and analysis!

What headers did curl receive when it did this? Could curl figure out that
there was a body coming after the headers? It seems as if it should detect
whatever situation that happens and behave accordingly, not just assume
something that may not be correct.

Would be able to setup a test case for me/us that could repeat this problem
on demand?

Also, could you please submit this as a bug report here:

http://sourceforge.net/tracker/?func=add&group_id=976&atid=100976

(I'm currently *drowning* in bug reports so I need them filed properly so
that I don't lose track of them.)

> 4. the app requests a POST with no parameters
> 5. curl sends the POST header
> 6. tomcat mistakenly sends the HEAD reply body
> 7. curl interprets the body as the header
> 8. curl defaults to a content-length of -1
> 9. curl waits for the timeout period to get exactly -1 bytes.

-- 
  Daniel Stenberg -- curl groks URLs
-------------------------------------------------------
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