Hi,
I'm not really sure, but I think using CURLOPT_HEADERFUNCTION might help you
- maybe try googling it around a bit.

Using: curl_setopt($ch, CURLOPT_HEADERFUNCTION, callback);
with: function callback($handle, $instring){echo $instring;}

Will give the same return as just using CURLOPT_HEADER. So I guess you can
just parse the data through that, and keep it out of your return.

-Stephen

2008/6/26 Troy Davisson <troy.davisson_at_gmail.com>:

> Hello all,
>
> Within my application, I have a few different activities that involve cURL
> which are causing some issues working together.
>
> The first involves Digest authentication. With CURLOPT_HEADER set to true,
> the message response comes back with a HTTP header chunk for the 401
> message, HTTP header chunk for the 200 message and the response body all
> returned as a single variable. This comes out to 3 distinct sections
> divided by blank lines. If, after authentication, I'm fed a redirect, cURL
> will follow it and introduce an additional HTTP header section causing even
> more problems.
>
> The second involves multipart messages. These don't come back in the same
> request as the Digest authentication, so chunk #1 is the HTTP 200 headers,
> chunk #2 is start of the response body, and chunk #3 is/can be seen as the
> first boundary information from the request. Blindly doing
> explode("\r\n\r\n", $response) to test for the correct pieces (like to find
> the first that comes back that doesn't start with "HTTP") breaks up the
> multipart message.
>
> So to my question:
>
> $response_headers = curl_getinfo($this->ch);
>
> appears to do a good job parsing the "correct" (last) header chunk. The
> issue I'm having is that the server sends back custom HTTP headers that I
> need to capture and verify, and the information returned from a
> curl_getinfo() request only includes the basic pre-defined headers. If I
> can get that to return all of the headers from the last HTTP header chunk, I
> can turn off CURLOPT_HEADER so I get back a clean response to be parsed
> separately. If I can't do that, I think I'm left to manually parse the
> entire response (CURLOPT_HEADER true) and figure it out from there.
>
> http_parse_message() from pecl_http seems to be a possible solution, but
> I'd rather not introduce another dependency in my project if I don't
> absolutely need to.
>
> Any suggestions or guidance is greatly appreciated.
>
> Troy Davisson
>
>
> _______________________________________________
> http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-and-php
>
>

_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-and-php
Received on 2008-06-27