< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

RE: [reSIProcate] RE: ServerAuthManager ?


I mean - only send a 407 once - the 2nd time send a 404 or something
else.  I'm envisioning a UA that always responds to a 407 with the same
proxy auth headers (with mismatched realm).  I don't think a UA is
likely to resubmit the request after a 404 response immediately (as
opposed to a 407 response).

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dale R. Worley
> Sent: Wednesday, February 22, 2006 5:27 PM
> To: Resiprocate-devel
> Subject: Re: [reSIProcate] RE: ServerAuthManager ?
> 
> On Wed, 2006-02-22 at 13:58 -0500, Scott Godin wrote:
> > > I've started working on async, I've also reported a new issue that
I
> > > will fix as part of the async patch:
> > >
> > >     http://track.sipfoundry.org/browse/RSP-29
> >
> > [Scott] We should be really careful about this.  We should only
issue a
> > 407 if we haven't already done so for this request.  If we don't do
this
> > check we could get into an endless loop with poorly behaved UA's.
ie.
> > UA's that always just send a bad realm, when challenged.
> 
> "As opposed to what?"
> 
> We could send a 400 in response to a second identical attempt that has
> the same authorization problem, but there's no guarantee that the UA
> wouldn't attempt to re-send after that, either.
> 
> If you mean, "Never send a 407 if it already has an authorization
> header." that won't work -- a request can legitimately have several
> authorization headers.  But maybe you have a way to detect whether a
> request really is a re-send in response to a 407 from this proxy.
> 
> Dale
> 
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel