I just tried http://localhost:631/admin and clicked "Add Printer" and a username and password prompt popped right up.  Comparing your net-log to mine I see your WWW-Authenticate response header had "Local" suffix that mine did not.  Here's a discussion of this exact issue:
  https://github.com/apple/cups/issues/5289#issuecomment-381729835

Asanka, can you take a look?  The claim is that the "Local" is an auth-scheme without any auth-params but Chrome seems to misparse it and not show the username/password prompt.

Interesting. Thanks, I wasn't able to find that bug report from CUPS.

It seems that according to RFC2068, realm is required:
  WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
  challenge = auth-scheme 1*SP realm *( "," auth-param )

However RFC7235 redefined WWW-Authenticate in the same way, but changed challenge to make realm just another auth-param, and make auth-params optional:
  challenge   = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

According to 7235 it looks like CUPS' line is standards-compliant.


Regardless it looks like my actual issue is more related to Ubuntu shipping an old version of CUPS.

The challenge header is:

   WWW-Authenticate: Basic realm="CUPS", Local

Local isn't meant to be a parameter. It should be parsed as a second authentication challenge. I.e. the header is equivalent to the following two headers:

   WWW-Authenticate: Basic realm="CUPS"
   WWW-Authenticate: Local

However, Chrome doesn't correctly deal with multiple challenges in a single header. This is a bug and should be addressed. So I'll leave the issue as 'available'.

In the meantime, it appears that CUPS has a workaround in place.

Can I start to work on this bug?

The problem is this: "Chrome doesn't correctly deal with multiple challenges in a single header", So change to implement is: 
make Chromium standards-compliant so that it recognizes that Local is not a parameter, but an authentication challenge, and so Chromium have to supports multiple auth-challenge in the same header?

#6: Sure! Have you worked with the Chromium codebase before?

Yes, I have already fixed some bugs in Blink. Ok, I'm starting to see this bug!

Cool. Feel free to reach out to me if you need any help.

Ok, thanks!

 Issue 888519  has been merged into this issue.

hmm. CC list didn't get copied over.

I responded on https://github.com/httpwg/http-core/issues/136 . After consideration, I'd much rather not have this additional complexity given that it doesn't really buy us anything. The only bug we've dealt with in the past was CUPS (this issue) and I believe they've started splitting challenges into their own headers.

luca94dd: Apologies for the change in direction. But if the spec authors are willing, I'd much rather this be a WontFix.

Regarding <https://bugs.chromium.org/p/chromium/issues/detail?id=872772#c4>:

For the spec arecheologists :-).

You missed the in-between RFC 2617.

RFC 7235 has generalized the ABNF, noting that "realm" is not part of the frame work but just specific to certain authentication schemes. Thus, it's not supposed to have a special role in parsing (remember: you need to parse the field value *before* you actually know what auth scheme(s) you're dealing with).

<http://test.greenbytes.de/tech/tc/httpauth/> has had tests for ages now, and bugs against browsers were filed back then.

asanka: I'm sorry if you don't hear from me these days, but I had a relocation in another country and I was a bit busy.
Howewer, RFC 7235 says that "User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and each
challenge can contain a comma-separated list of authentication
parameters [..]" (section 4.1, https://tools.ietf.org/html/rfc7235#section-4.1)

I have read the discussion you linked and seems that no browsers implement this.
So we leave this as is? 

#16: Yup. There's no dispute that the current behavior deviates from the spec.

The question at this point is whether to update the spec to match the existing implementations or to update implementations to match the spec. I'm arguing for the former.

There is no interop concern given that none of the top browsers implemented it for so many years. Hence AFAIAC the only motive would be if this change made something possible or substantially easier than before. This is also not the case. At this point the grammar allowing for multiple challenges in a single header value is arguably de-facto rejected by implementers.

Firefox handles CUPS's "WWW-Authenticate: Basic realm="CUPS", Local" perfectly.

Do you not consider Firefox a top browser?

Julian (#15): Ah. I see  issue 103220  got archived for similar reasons as #17.

P.S. - To be clear, I think either resolution is acceptable: getting it removed from the standard, or supporting it.

> Firefox handles CUPS's "WWW-Authenticate: Basic realm="CUPS", Local" perfectly.

That's a broken header field, and the most plausible behaviour would be to ignore it.

> P.S. - To be clear, I think either resolution is acceptable: getting it removed from the standard, or supporting it.

"Removing it from the standard" means adding a special case where none is needed for interop.

How is it broken?

Direct quote from 7235:
     WWW-Authenticate: Newauth realm="apps", type=1,
                       title="Login to \"apps\"", Basic realm="simple"

#20: Understood. I was going by https://bugzilla.mozilla.org/show_bug.cgi?id=1493686 and others linked off of https://github.com/web-platform-tests/wpt/pull/13189. I didn't personally go through and check every browser.

#22: Yeah, I'm not sure why the CUPS line is considered broken. Julian?

> #22: Yeah, I'm not sure why the CUPS line is considered broken. Julian?

It's not broken. Sorry. "Local" should parse as a single parameter-less challenge.

#26: explaining further: my test suite at <http://test.greenbytes.de/tech/tc/httpauth> was implementing a draft version of RFC 7235, thus my confusion. I have now fixed this, see <http://test.greenbytes.de/tech/tc/httpauth/#multibasicunknownnoparam>

Julian: Does there exist a combined grammar of standard header fields? I'm trying to reason about the simplest header parser that doesn't need special treatment for coalesced auth headers.