From: Paul Kyzivat <[EMAIL PROTECTED]>
I'm far from sure, but I think it may be possible for a forking proxy to
get 407 responses from multiple forks, and to combine the
Proxy-Authenticate headers into a single 407 response. If this were
done, then a retry that contains two Proxy-Authorization headers could
fork and succeed on both forks.
Uh, what? "far from sure"? You must be busy at work and have gotten
distracted -- the behavior you describe is mandatory. RFC 3261,
section 16.7 "Response Processing", item 7:
7. Aggregate Authorization Header Field Values
If the selected response is a 401 (Unauthorized) or 407 (Proxy
Authentication Required), the proxy MUST collect any WWW-
Authenticate and Proxy-Authenticate header field values from
all other 401 (Unauthorized) and 407 (Proxy Authentication
Required) responses received so far in this response context
and add them to this response without modification before
forwarding. The resulting 401 (Unauthorized) or 407 (Proxy
Authentication Required) response could have several WWW-
Authenticate AND Proxy-Authenticate header field values.
This is necessary because any or all of the destinations the
request was forwarded to may have requested credentials. The
client needs to receive all of those challenges and supply
credentials for each of them when it retries the request.
Motivation for this behavior is provided in Section 26.
After all, it's the only way to handle the situation that will
actually work.
BTW, I don't see what all the fussing is about on this topic -- in
every case, there is only one behavior that will actually make the SIP
system work robustly. So why are people puzzling over it?
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
