Digest authentication thowing errors in Jena 4.3.X and newer about jena HOT 4 CLOSED

So the HTTP Authentication Challenge is coming back from whatever SPARQL server you are interacting with which you haven't specified.

I'm unclear whether the individual parameter fields within the WWW-Authenticate header are permitted to have whitespace or not.

Following the grammar an auth-param rule says Bad Whitespace may be present per RFC 7230 Section 3.2.3:

auth-param = token BWS "=" BWS ( token / quoted-string )

The BWS rule is used where the grammar allows optional whitespace
only for historical reasons. A sender MUST NOT generate BWS in
messages. A recipient MUST parse for such bad whitespace and remove
it before interpreting the protocol element.

 OWS            = *( SP / HTAB )
                ; optional whitespace
 RWS            = 1*( SP / HTAB )
                ; required whitespace
 BWS            = OWS
                ; "bad" whitespace

The upshot of which is servers MUST NOT be producing whitespace here BUT recipients i.e. Jena, should strip and ignore such bad whitespace.

Although that seems to be between parameters not within the parameters itself, the relevant grammar rule actually looks to be quoted-string (RFC 7230 Section 3.2.6) which says:

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

Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.

 comment        = "(" *( ctext / quoted-pair / comment ) ")"
 ctext          = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text

The backslash octet ("") can be used as a single-octet quoting
mechanism within quoted-string and comment constructs. Recipients
that process the value of a quoted-string MUST handle a quoted-pair
as if it were replaced by the octet following the backslash.

Which boils down to new lines not being valid in these parameters AFAICT. So this looks like probably a server bug but maybe an area where Jena could be more forgiving?

from jena.

The problem is in the outgoing credentials request after the 401 challenge.

It is the SPARQL string not being encoded and it has a newline in it; the JDK rejects the request locally. The server has only sent the 401 challenge which is legal and isn't involved in the exception cause at Utils.newIAE.

The "uri" auth param in a digest is the "request-target". That includes the query string by my reading of RFC7616->RFC7230 section 5.5

But that does not make sense in our situation

• "?query=" and POST+application/sparql-results should be the same authentication. It is not like /path?client=1234 where the query string is a subresource.
• The auth support is by URI path and realm, not query string. The users/password applies to the endpoint.

So for the SPARQL case, a request-target of the URI path make sense to me (no query). This work with Jetty. This is not surprising because the Jetty resource is named by the URI without query string.

Putting in the encoded query also works with Jetty HttpLib.requestTarget - use getRawQuery not getQuery.

from jena.

Extra oddity: as query strings for SPARQL can be long, there is a chance the HTTP request will exceed the server limit on request headers - the URI will be in the headers twice (request line and "Authentication" header). The total limit is often 8K but some nginx is 4K.

from jena.

FYI - The server I am executing this against is Virtuoso.

from jena.