(sent off-list by mistake last night -- resending -- sorry)

-DB

> On Mon, 6 Oct 2003, Daniel Stenberg wrote:
>
> > On Mon, 6 Oct 2003, David Byron wrote:
> >
> > I'm seeing some behavior I don't expect from curl during an http
> > POST and was wondering if anyone can clarify this for me. I've read
> > a bit of RFC 2616 but probably not enough to know for sure what's
> > "supposed" to happen.
> >
> > I invoke curl like this:
> >
> > $ curl --fail -F File=@<some file> <some url>
> >
> > From looking at the trace, the server sends back a 100-Continue
> > message, and curl proceeds to send the file. One of our tests
> > involves stopping the server after it sends the 100-Continue, so
> > curl doesn't receive any more data over http. The part that seems
> > odd to me is that curl still has an exit code of 0.
>
> That would mean that curl didn't notice anything wrong with the
> connection. What exactly does "stopping the server" mean?

Stopping IIS, but leaving the rest of the machine running.

> > When we leave the server running normally, it responds with a 200-OK
> > message after curl sends the entire file.
> >
> > Is it expected/desirable for curl to return some error if it never
> > gets the final OK message?
>
> No. curl always reads the response code, and getting a 404
> is just as good for curl as a 200 is. The HTTP status code does not
> tell curl about errors, they are for the humans/programs that run
> curl.

I haven't gotten the protocol analyzer out, but curl's trace doesn't include
any response at all after the 100-Continue. That's why I figured there would
be some kind of error.

As in my other uses of curl, I'm using --fail here, so I'm hoping for a
non-zero return code.

-DB

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2003-10-07