On Tue, 10 May 2005 man_at_tfhs.net wrote:

> transfer.c, line 288 calls Curl_select(). curl select returns 4 (error). the
> code below line 288 only looks for the lowest two bits of the return (read
> and write). it does nothing with the error at all.

Gosh!

> it also appears to have done nothing with the results it has read thusfar
> from the server, so it does not notice the 407?

It takes care of all incoming data the usual way. What makes you think it
"have done nothing" ?

> my trivial code change sofar has been to if(error){return CURLE_SEND_ERROR;}

I suggest adding this:

   if(select_res & CSELECT_ERR) {
     failf(data, "select/poll returned error: %s",
           Curl_strerror(conn, Curl_ourerrno()));
     return CURLE_SEND_ERROR;
   }

> but that is not really good, since i dont actually know if it was a SEND
> or a RECV error (curl_select does not say)

The underlying layer doesn't say either, so let's just pick one of them and
include the full message in the error message.

> we actually have all the data we need to do the retransmit with auth. what
> it should do (i guess),

> if(error){
> look in read buffer for 407
> jump to retransmit with auth code
> }

No. If we should treat 407 differently than today, we should add code to deal
with it the same way we deal with other http response codes. And this needs to
be done after all headers have been received. See how 100 and 417 is treated
in lib/transfer.c (around line 480 in my file).

I say 'if' here, because this is a mine field you're entering and I advice you
to tread gently. HTTP auth and POST combined have caused me some grief over
the years...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html