Ok, the problem here is that what we expect to follow qop= is context-sensitive; in an Authorization-type header, we expect to find a qop-value (a non-quoted token), but in an Authenticate-type header, we expect to see a qop-options (a quoted, comma delimited, sequence of tokens). Unfortunately, there is currently no way to make the parse code context-sensitive. The API for Parameter would need to change (right now, it just looks for a quote, and if it is there, it assumes we were looking for a qop-options). Additionally, both Authorization-type and Authenticate-type are the same class (Auth), so it is doubtful that this context info is even availabe in the first place. Any opinions on how we can make this code context-sensitive with minimal impact on the rest of the code?
Best regards, Byron Campen I thought this had been fixed already at a few SIPits. I know it's been identified.
We should accept with or without quotes. We must never send with quotes (in this header field - the answer's different for the challenge).
RjS On Jan 22, 2007, at 9:18 AM, Matthias Moetje wrote: Byron, thanks for the reply. The BNF in the RFC specifies that the qop in Proxy-Authorization and Authorization header-field-values is unquoted. People have thrown around the idea of having resip allow the quoted version, but it appears that this hasn't yet been done. Should we just go ahead and do this for interop's sake? I’d vote for doing so. Even if it is correct that the RFC doesn’t allow quotes here, it is still wrong to classify it as qop-Options in this context… I would fix it myself but I don’t have subversion installed currently and I am still unsure how to determine when to parse it as qop-Options and when as qop because inside this function the required information (is it authentication or authorization) is not available… Best regards, Matthias Moetje
<image001.jpg>
| TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY | | | <image001.jpg> _______________________________________________ resiprocate-devel mailing list
|