cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: http status code early?

From: David Boyce <dsb_at_world.std.com>
Date: Fri, 04 Apr 2003 13:43:44 -0500

>I played around a little bit with this today. As you say, it does look to
>me like you can get this via curl_easy_getinfo() from within the context of
>a write callback (i.e. while curl_easy_perform() is executing) for both 200
>and 404 conditions. I didn't test anything else.
>
>Thinking back, the reason I did what I did was because I needed to know
>what the return status was before I ever got my first write callback.
>
>Maybe it is too specialized of a callback, but I suppose curl could add
>another that would callback as soon as the status was parsed. This might
>benefit the original poster who was not using write callbacks in the first
>place.
>
>typedef size_t (*curl_status_callback)(int code, void *userdata);
>
>User could could return 0 to continue or !0 to tell curl it didn't like the
>status and just abort right there.
>
>I suppose it gets down to the level granularity provided. The info is
>there and you can get at it, the question is whether it should be more of a
>"first-class" api.

Understand that I'm pretty new to curl and no HTTP guru, so apologies if
this just doesn't make sense. But why not break the functionality of
curl_easy_perform() into two functions: curl_easy_get_headers() and
curl_easy_get_body(). The original curl_easy_perform() would become a
wrapper function calling these consecutively. Existing code and recommended
coding practice are unaffected, but people who need to can call
curl_easy_get_headers(), then do whatever they like based on what they see
there via curl_easy_getinfo(), then call curl_easy_get_body(). I suspect
this would require a little extra buffering logic as the underlying TCP
transport doesn't respect the division between headers and body but that
seems like a SMOP :-)

The above proposal would work fine too, though I'd replace "as soon as the
status was parsed" with "as soon as the headers are parsed". Any solution
should provide a general-purpose hook to look at all headers before
processing the body, IMHO. I guess the other problem with this is, can you
be sure all headers will fit in the first buffer's worth? I.e. are all
headers guaranteed to have been read by the time the first callback is made?

David

PS My ISP's spam filter is currently preventing me from getting replies on
the list, so I'm reduced to following the thread via the news gateway at
gmane.org. I'm attempting to preserve threading by responding to my
original msg.

-------------------------------------------------------
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-04