cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: what to do with incoming data we don't want?

From: Dan Fandrich <dan_at_coneharvesters.com>
Date: Thu, 12 Jun 2003 10:27:48 -0700

On Thu, Jun 12, 2003 at 07:11:05PM +0200, Daniel Stenberg wrote:
> Hi
>
> With this new authentication support (Digest, GSS-Negotiate and NTLM) we've
> introduced a new problem to libcurl which I think we need to address somehow:
>
> They all deliver one or more pages with contents that isn't what the user of
> libcurl wants but is delivered anyway... libcurl currently has no concept of
> "hiding" data or silently ignoring it. What to do?
>
> NTLM is a fine example:
>
> Currently it works like this (one round-trip could probably be moved out):
>
> 1) GET
>
> 2) 401 returned (with page contents)
>
> 3) GET
>
> 4) 401 returned (with page contents)
>
> 5) GET
>
> 6) 200 returned, with the contents we care about
>
> So, in step 2 and 4 (or if we cut out 1 we won't get number 2, only 4) we get
> contents we don't need, like or want. We need to read it since we want to
> re-use the same connection.
>
> Should I simply introduced another state to the debug callback and provide
> all that data to it and smile, or is there anything more to it than I'm
> thinking of right now? This would of course only hide the data if everything
> is working OK, if anything goes wrong in the authentication it would produce
> the data "as usual" when a bad HTTP password is used.
>
> Thoughts? Other approaches?

Why not treat them the same way libcurl treats 30x redirect codes with
FOLLOWLOCATION enabled, whichever way that is? The page contents for 401
codes are just as useless as the contents of 301 codes; only the headers
matter.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved
-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
Received on 2003-06-12