From: "Joseph C T - NPD, Chennai" <[EMAIL PROTECTED]>
I see that http://www.hcltech.com contains only a Flash animation,
with no alternative for browsers that do not support Flash. That's
not a good example of compatibility.
Is there any chance for a scenario like this
UA1->P1->P2->P3->UA3 ,where P1 and P2 are in the same domain
and use same realm.
Yes, such a scenario could easily happen. The first request will
cause a 407 at P1. The UAC will provide an authorization based on
P1's challenge and re-send the request. The second request will pass
P1 and cause a 407 at P2 (assuming that P2 requires a separate nonce).
That 407 will be returned to the UAC, which will construct a second
authorization based on the second 407. The third request will have
both authorizations, it will pass P1 and P2 and arrive at UA3.
This is a direct consequence of the rules in RFC 3261.
BTW, it would help if you indented your quoted material, as has been
the standard on the Internet since 1980 or earlier. The "[Joseph]"
flags do not make your contribution stand out well.
[Joseph] After P1 forwards the first 407 it removes it own authorization
header from the request.When this reaches at P2 then again P2 will request
for authentication.This 407 is again given to the UAC through P1.This time
the UAC sees this as a failure of credentials for the prevoius request and
sends again to the user to key in the username and password.This willl agin
the request with one authorization header.Now again while passing through P1
it strips the authorization header from the request.Will this not create a
loop?
No, because you're not analyzing the situation correctly. The *third*
request (described above) will have *two* Authorization headers, one
carrying the nonce given by P1, and one carrying the nonce given by
P2. P1 may remove the first Authorization (though it really
shouldn't, as doing so can do no good and causes harm in some
scenarios), but it should never remove the second Authorization (as it
is not directed toward P1, as P1 can easily verify). The second
Authorization reaches P2, and allows the request to pass P2.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
