I also needed to know the HTTP response code prior to receiving the content
(and hence before curl_easy_peform() returned).

The way I did it was to setup for the CURLOPT_HEADERFUNCTION callback, and
in there parse the response code out of the header manually. Then I
stuffed that value away in a place accessible from the other callbacks so
they knew how to behave based on the response.

Kind of hacky, but it was the only way I could see to do it. I suppose
this might be a feature that is desirable to others, maybe a more standard
solution could be identified.

                                                                                                                                                   
                      David Boyce
                      <dsb_at_world.std.com> To: curl-library_at_lists.sourceforge.net
                      Sent by: cc:
                      curl-library-admin_at_lists.sour Subject: http status code early?
                      ceforge.net
                                                                                                                                                   
                                                                                                                                                   
                      04/03/2003 12:42 PM
                      Please respond to
                      curl-library
                                                                                                                                                   
                                                                                                                                                   

I have a Unix command-line tool based on libcurl. The program itself is
just a thin wrapper which makes an http request to a servlet and pumps the
response out to stdout. There's no need for the user to know (not that it's
a secret either) that it's an http based tool; they just run commands and
get results, in text/plain format, on stdout. This works nicely.

There's just one minor problem. A well behaved command-line tool sends data
to stdout and error messages to stderr. But HTTP doesn't have two streams,
just the unitary response body. So as currently configured all output,
including errors, is streamed to stdout. I don't use any callbacks
(CURLOPT_WRITEFUNCTION), I just let the response flow to stdout.

I'm looking for a way to divert error output to stderr. The obvious
solution is for the server to set the response code to something
representing an error (presumably in the 4xx range) and set the exit status
and output stream of the client based on that. I've set this up and it
works great for the exit status, because of course I don't need that till
exit time. But the stdout/stderr determination is a problem because the
documentation for curl_easy_getinfo() says this:

>This function is intended to get used *AFTER* a performed transfer, all
>results from this function are undefined until the transfer is completed.

So I can't get the response code till after the data has flowed to stdout.
Of course I could set a callback and buffer all the output using malloc or
a temp file but that's a long ways from elegant, esp. since the output is
unbounded. I'm wondering if there's a cleaner way to handle this that I've
missed, and in particular why the response code (and all the header data)
isn't valid until after the entire response body is read given that the
headers must arrive frst.

Thanks,
David

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
Received on 2003-04-03