Comments (4)
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.
Related Issues (20)
- `UNDEF` in `VALUES` doesn't work with `SERVICE` HOT 4
- Provide a framework for normalizing RDF terms
- Titanium JSON-LD processor no longer supported HOT 1
- Move test log4j setting from log4j.properties to log4j2-test.properties
- Inconsistent default graph handling in RIOT writers HOT 3
- RDFLink: API for passing raw query strings to backend HOT 3
- java.lang.Error: Maximum lock count exceeded HOT 8
- SPARQL query round-trip serialization error HOT 1
- `jena-arq` module introduces a JUnit dependency into compile scope HOT 1
- Clean up AuthBearerFilter
- Align building of shared jars
- Upgrade to vitest v2.x
- org.apache.jena.fuseki.servlets.ActionErrorException: Cannot read field "succ" because "n" is null HOT 2
- Shiro 2.X doesn't allow plain text password in user section of shiro.ini HOT 2
- RDFXML: can't parse rdf:XMLLiteral when round-trip HOT 5
- RDFXML: possible to load incorrect XML HOT 8
- is this well formed rdf xml? HOT 3
- DocumentGraphRepository: prevent double loading of the same graph
- RRX: Make unqualified class, unqualified properties and xml attributes an error.
- RRX: Make unqualified, unrecognized attributes an error.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jena.