[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Will the http.set_auth call in rhc ever happen?

On Thu, Jun 20, 2013 at 10:16:50AM -0400, Clayton Coleman wrote:
> There's the possibility that a subclass would want to craft a special httpclient_for, but it's unlikely.  However, since they're two separate methods if you removed the setter there would be no way for a different consumer of httpclient_for to pass into the HTTPClient user object.

Ah, subclasses.

> The section setting the authorization header directly is to work around the behavior in HTTPClient that lazily auths each time when set_user is used.  I'm sure there's a case in where someone would want to to call set_user, but if they did we'd need to come up with a different option in the hash.

Yep, I can see the delete and forcing Basic was done in commit


to avoid the initial 401 round trip. And indeed, the RFC allows that:

   14.8 Authorization
	A user agent that wishes to authenticate itself with a
	server--usually, but not necessarily, after receiving a 401
	response--does so by including an Authorization request-header
	field with the request.

The tiny drawback is that it takes away the possibility of doing
for example Digest.

Thank you for the explanation,

Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Engineer, Identity Management Engineering, Red Hat

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]