On Tue, 5 Feb 2002, Roth, Kevin P. wrote:

> Tried compiling on Cygwin. make test fails on number 3 now (the httpserver
> sits forever waiting for the line of text coming in; guessing this is
> related to the CR/LF change you made for HTTP posts).

Yeps, I haven't even tried running anything on the test suite the last week.
I have been doing some slow work on the replacement http test server though.

> But what's worse - when I try a simple test against my internal SSL server,

This is just a GET, right? Does it do this for all SSL tests you do?

> the curl client waits forever for the final line of response text. An older
> version of curl receives it just fine.

Older as in how old? Does 7.9.3 work but 7.9.4 doesn't?

> Interestingly, the newline character between these two lines is being
> returned from my web server (a MICROSOFT server no less) as just a unix
> line-feed character (LF, 0x0a, \n) instead of the more normal windows
> line-feed (CRLF, 0x0d0a, \r\n).

HTTP says they should be CRLF, but curl is supposed to accept either way.

> Here's another example - this one actually works, but as you can see, one
> of the lines is printed in the wrong spot in my verbose output:
>
> $ curl -v -i https://sweb.fdy.moc.com/
>
> HTTP/1.1 200 OK
> Server: Microsoft-IIS/4.0
> Content-Location: https://sweb.fdy.moc.com/Default.htm
> Date: Tue, 05 Feb 2002 13:44:58 GMT
> Content-Type: text/html
> Accept-Ranges: bytes
> Last-Modified: Fri, 03 Sep 1999 20:59:14 GMT
> ETag: "0bd8c2d4ff6be1:578b5"
> Content-Length: 374
>
> This is the Secure Web virtual server.
> <P>
> HTTP is on the standard port 80 of sweb.fdy.moc.com if your browser
> supports hos
> t headers, otherwise it's on port 8081.
> <P>
> HTTPS traffic is on the usual port 443.
> <P>
> Note to self: requests from browsers for sweb.fdy.moc.com if they
> don't support
> host headers will go to mweb. So I'm not messing anything up!
> <P>
> * Connection #0 left intact
> * Closing connection #0
> --Kevin
>
> Note that "--Kevin" appears AFTER the Closing-connection lines... This
> sample uses windows (CRLF) end-of-lines, but there isn't one after the
> final line ("--Kevin").

This might just as well reflect the fact that stderr is non-buffered, while
stdout is and the *-lines go to stderr while the contents go to stdout. At
least I can't see any obvious error in this.

> Being not a C programmer, and not having much time to become one, I'm not
> going to be of much help in fixing this. However, if you need any further
> diagnostic info from me, don't hesitate to ask.

That first "hanging" request, is that a server/URL I can try from my place?

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/