Basic authentication fails if realm is single quoted and has a blank in the value

[SailReal]

Using Cryptomator for Android, we stumbled over the following problem: Davros server does respond with an single quoted basic realm: "WWW-Authenticate: Basic realm='Sandstorm API'". This together with the fact, that the realm has a blank in the value, leads to not creating a challange in HttpHeaders.Buffer.readChallengeHeader()

Using OkHttp "WWW-Authenticate: Basic realm=\"Sandstorm API\"" and "WWW-Authenticate: Basic realm='SandstormAPI'" works but "WWW-Authenticate: Basic realm='Sandstorm API'" not.

As also mentioned in mnutt/davros#74 (comment), RFC7617#section-2 only says that it can be a quoted string with the example "WallyWorld". I just tested it with a list of common WebDAV servers which all responds with the double quoted variant. But other clients also accepts blanks in single quoted string. So I really don't know exactly which party I should ask to fix this as also mentioned in mnutt/davros#74 (comment).

The easiest way to reproduce it, is to add those two tests to HeadersTest.java:

  // works
  @Test public void basicSingleQuoteNoBlankChallenge() {
    Headers headers = new Headers.Builder()
            .add("WWW-Authenticate: Basic realm='protected'")
            .build();
    assertThat(HttpHeaders.parseChallenges(headers, "WWW-Authenticate")).isEqualTo(
            singletonList(new Challenge("Basic", singletonMap("realm", "'protected'"))));
  }

  // fails
  @Test public void basicSingleQuoteWithBlankChallenge() {
    Headers headers = new Headers.Builder()
            .add("WWW-Authenticate: Basic realm='protected area'")
            .build();
    assertThat(HttpHeaders.parseChallenges(headers, "WWW-Authenticate")).isEqualTo(
            singletonList(new Challenge("Basic", singletonMap("realm", "'protected area'"))));
  }

[yschimke]

I think given the ambiguity and risk of breaking existing behaviour, we'd be more inclined to change this given examples from Web Browsers e.g. Chrome or Firefox. What do they do?

[SailReal]

What do they do?

Firefox and curl allows blanks in single quoted realm values.

According to the RFC, a blank is allowed in the value of the realm. From my point of view, the RFC does not specify whether it has to be double quotes or it can be single quotes as well, but a blank is explicitly allowed. In my opinion, if OkHttp already supports single quotes in general, blanks in single quotes should be supported too.

[yschimke]

I think technically that's covered here https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.6

3.2.6.  Field Value Components

   Most HTTP header field values are defined using common syntax
   components (token, quoted-string, and comment) separated by
   whitespace or specific delimiting characters.  Delimiters are chosen
   from the set of US-ASCII visual characters not allowed in a token
   (DQUOTE and "(),/:;<=>?@[\]{}").

     token          = 1*tchar

     tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                    / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                    / DIGIT / ALPHA
                    ; any VCHAR, except delimiters

   A string of text is parsed as a single value if it is quoted using
   double-quote marks.

     quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
     qdtext         = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
     obs-text       = %x80-FF

[SailReal]

I think technically that's covered here https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.6

Ah nice, thanks 👍, that sounds very clear but still raises the question why single quotes in general are supported but blanks in single quotes not 🤔.

[yschimke]

Yeah, I don't know the answer here. But at least for headers double quotes are "quotes" I believe.

[yschimke]

Going to close this given it's outside spec, and I'd be nervous about breaking current behaviour. I doubt we will fix based on the rare occurence here.