Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 1 user
Status: Fixed
Closed: Nov 2010
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment
Incorrect digest authentication behavior with less common qop values
Reported by, May 27 2010 Back to list
Chrome Version: Google Chrome, 5.0.375.55 (Official Build 47796) beta
URLs (if applicable):
Other browsers tested:
  Firefox 3.x: OK

There are several quirks with Chrome's HTTP digest authentication 
(specified in RFC 2617) that seem noncompliant, though none of them too 
pressing. They are valid combinations which the RFC say Chrome should 
accept, and it does, but behaves oddly. To reproduce two of them I've 

1. Connect to a server which sends a digest challenge qop="auth-int"
2. Chome will send back a response containing qop=auth-int, but where the 
second hash component does not include the hashed entity body, as is 
required in this case.

1. Connect to a server which sends a digest challenge qop="auth,auth-int"
2. Chrome will send back qop=, but use the variant of the response hash 
with a nonce count, client nonce, and (empty string) qop, which requires a 
response of either qop=auth or qop=auth-int.

I've attached a text file containing the authentication headers, obtained 
from a Wireshark capture of the loopback interface, with analyses of 
Chrome's response. The server is Happstack, a Haskell framework, and I was 
writing a module to do digest authentication when I came across these 

As auth-int isn't too commonly used, this shouldn't affect too many 
client/server interactions in the wild. Nonetheless, Firefox seems to 
handle the requests fine: if given auth-int, it ignores it, falling back to 
the RFC 2069 standard if nothing else is specified, which is permitted by 
RFC 2617.
4.8 KB View Download
Labels: -Area-Undefined Area-Internals OS-All Internals-Network
Status: Untriaged
Status: Assigned
Thanks for this detailed bug report - and sorry for the long delay in reacting to it.

I will change the digest handler to ignore auth-int rather than pretend to use it without actually incoporating the body into the digest. There's a number of reasons _not_ to support auth-int, and we should stop pretending that we do. 
Sure. Just the other week I was browsing, and I see the situations are well-defined, but making the server module I was just following the RFC. If only it were as full-featured as most cookie session controllers :) Thanks for the help.
Comment 4 by, Nov 15 2010
The following revision refers to this bug:

r66137 | | Mon Nov 15 10:30:14 PST 2010

Changed paths:

Improve unit test coverage of HttpAuthHandlerDigest parsing.

Also, if the only qop is auth-int, use a different handler since this is not currently handled.

BUG= 45194 
TEST=net_unittests --gtest_filter="*HttpAuthHandlerDigest*"

Review URL:
Status: Fixed
Marking this fixed for the case described.

auth-int is simply ignored. If auth-int is the only qop advertised by server, the digest handler will fall back to RFC 2069 behavior. If auth and auth-int qop values are advertised, auth qop will be chosen.
Project Member Comment 6 by, Oct 12 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 7 by, Mar 10 2013
Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network
Sign in to add a comment