[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?



If the methods need to change to accomodate DIGEST I think that's very reasonable - the mechanism just needs to be correctly integrated.

----- Original Message -----
> 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
> 
> 	cf8f084bc8586e787466bbd85ac80726ebc0945a
> 
> 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]