I tried to reproduce this a couple of days ago and was unable to. I'm
trying to dig up the code where I saw this issue, it was a few weeks ago
when I wrote it. I'll update once I find out more.

On Sun, Mar 20, 2011 at 9:35 AM, Julien Chaffraix <
julien.chaffraix_at_gmail.com> wrote:

> >> Olivier is correct, this is what I am seeing, also. In order to view
> the
> >> final status code, I had to implement a header function and manually
> parse
> >> out the 2nd response code when the request is completed. Since, per the
> >> spec, a final status code is required in all cases, as far as I can
> tell, it
> >> seems reasonable to make the 2nd response code the value returned from
> >> CURLINFO_RESPONSE_CODE in all cases.
> >
> > I can only agree and I consider this a bug.
>
> I had a look at this bug today and I could not reproduce it. I have
> attached the test I run. I don't see the 100 response code that you
> mentioned which likely means that I am not testing the same
> conditions.
>
> Olivier and Jorge, could you give us more info about your libcURL
> version and some instructions to reproduce this on our side? Even
> better do you have a reduced program that shows the bad behavior?
>
> Thanks!
> Julien
>
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-03-20