[PATCH 1 of 1 STABLE] http digest auth: reset redirect counter on new requests (issue2255)

[Wagner Bruna]

Wagner Bruna wrote:
> # HG changeset patch
> # User Mads Kiilerich<mads at kiilerich.com>
> # Date 1277586058 -7200
> # Branch stable
> # Node ID f19b6d8ae201d91396a4e32157c1c1698efb45ed
> # Parent  b9a46acdfe1f8f5c5c0ff63bf759b590e6780c81
> http digest auth: reset redirect counter on new requests (issue2255)

Matt Mackall wrote:
> Why is Mads' name attached to this?

As explained, he wrote that patch; sorry for not being clearer.

Mads Kiilerich wrote:
> It _is_ a high risk patch, but I am not sure it is more risky than using
> urllib2 in general. The impact of issue2179 was however smaller than the
> potential impact of this patch combined with previous and future
> versions of urllib2.
> 
> The handling of redirects in urllib2 seems to be fundamentally broken.
> The redirect counter in digest auth is hardcoded to stop after 5
> redirects, but the counter is reset on (some) redirects (sic!) and will
> thus loop forever in some cases. The counter will however not be reset
> in any other cases, so when the digest auth is resued for several
> requests (for example when exploring remote changesets) the counter will
> reach the limit.

The current code always tries an unauthenticated request first, even
after the first authenticated request is accepted successfully. So we
get a 401 for each request, and each of those increments the redirect
counter.

A better approach could be to somehow reuse the authentication
information from the first try on subsequent requests: that way we
wouldn't increment the redirect counter for each request (the
discovery time would also be much improved). But I'm not sure that'd
be possible without major replacing of urllib2 code...

Regards,
Wagner

> In python 2.6.6 (and apparently backported to debian 2.6.5) basic auth
> has the same feature.
> 
> /Mads