On Sun, 2005-11-20 at 14:31 +0000, sebb wrote: > On 20/11/05, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Sat, 2005-11-19 at 18:50 +0000, sebb wrote: > > > > I respectfully disagree. In the HTTP spec quote marks are always > > > > designated as <">. See request-digest in the example above > > > > > > I can't find qop-value defined anywhere as a quoted string, but nor > > > can I find it defined as a non-quoted string. > > > > > > But why does the RFC use the unq() function on qop-value unless it is > > > a quoted string? > > > > > > There are some other examples of the use of unq() - e.g. realm-value - > > > in each case all of the operands are defined as being quoted strings. > > > > > > > All right. This is how it goes > > [snip] > > > Hope this makes things clearer > > Indeed it does, thanks very much - sorry to put you to the trouble. > Dunno how I missed the example... >
No trouble of what so ever > Why the RFC uses unq() on qop-value is a mystery - the only purpose > seems to be to confuse readers ;-) > Very much so. There are other discrepancies and contradictions in the RFC2617 we know of > It will be interesting to find out what combination of quotes is > accepted by the Map Point service ... if it turns out that quite a few > servers insist on quotes, then it might be worth making this an > option. > If unquoted qop-value does turn out to be the only reason the digest response gets rejected, we will consider providing a parameter to always enclose qop-value in quotes > > > > Cheers, > > > > Thanks for your patience. > No worries. Thanks for taking interest in HttpClient Oleg > S. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
