HttpLoader doesn't properly process missing content-type about titanium-json-ld HOT 11 CLOSED

In my app, I set MediaType.JSON_LD on context and JSON on input,
and I keep having deterministically the same IllegalArgumentException.
Which means it works with some data, and not with others, seemingly similar, but always the same way.
Works with
http://semantic-forms.cc:1952/json2rdf?src=https://beta.grottocenter.org/api/v1/entrances/4
IllegalArgumentException with:
http://semantic-forms.cc:1952/json2rdf?src=https://beta.grottocenter.org/api/v1/massifs/333
The @context by default (context= for HTTP service) is
https://github.com/jmvanel/Karstlink-ontology/raw/master/grottocenter.org_context.jsonld
The code is here:
https://github.com/jmvanel/semantic_forms/blob/master/scala/forms_play/app/controllers/Json2RDFServiceApp.scala#L47

Titanium maybe should not demand a content type for a context JsonDocument, because a context, I think, should necessarily be a JSON-LD Document.
And for the input of toRdf() , I don't know if there is any difference in processing if it is JSON or JSON-LD .

from titanium-json-ld.

The first issue is that your sever does not add content-type HTTP header to a response with a content. This issue addresses that Titanium does not expect that and fails.

from titanium-json-ld.

Regarding text/plain. I'm sorry but HttpLoader cannot anticipate when text/plain means application/json. If content-type does not properly reflect the content then I would recommend to write a custom loader that wraps HttpLoader and rewrites the content-type header to the proper one.

from titanium-json-ld.

But the point is that in the first place the data source was created by JsonDocument . of() , so it is necessarily JSON, but that information should not be lost in the implementation chain .

from titanium-json-ld.

I'm sorry, but I don't understand. As you can see from the stacktrace HttpLoader is involved and causes the exception. Perhaps, the document you pass contains a link on a context?

from titanium-json-ld.

The new code fixes my problem, even though the context
https://github.com/jmvanel/Karstlink-ontology/raw/master/grottocenter.org_context.jsonld
is still the same, with text/plain Content-type .

from titanium-json-ld.

You should see warnings if sl4j is configured.

e.g.

AVERTISSEMENT: GET on URL [http://...] does not return content-type header. Trying application/json.

from titanium-json-ld.

sl4j was configured and indeed, AVERTISSEMENT is present:
AVERTISSEMENT: GET on URL [https://ontology.uis-speleo.org/grottocenter.org_context.jsonld] does not return content-type header. Trying application/json.

Whether this deserves a warning is a matter of taste. A JSON processor like Titanium, for the toRDF call, cannot try anything but JSON...

from titanium-json-ld.

HttpLoader is used generally not by just toRdf ...

FYI:

The data type of the representation data is determined via the header
fields Content-Type and Content-Encoding. These define a two-layer,
ordered encoding model:

representation-data := Content-Encoding( Content-Type( bits ) )

https://tools.ietf.org/html/rfc7231#section-3.2

and

In practice, resource owners do not always properly configure their
origin server to provide the correct Content-Type for a given
representation, with the result that some clients will examine a
payload's content and override the specified type. Clients that do
so risk drawing incorrect conclusions, which might expose additional
security risks (e.g., "privilege escalation"). Furthermore, it is
impossible to determine the sender's intent by examining the data
format: many data formats match multiple media types that differ only
in processing semantics. Implementers are encouraged to provide a
means of disabling such "content sniffing" when it is used.
https://tools.ietf.org/html/rfc7231#section-3.1.1.5

Missing content-type breaks one of the core HTTP principles content identification and negotiation ...

from titanium-json-ld.

But this is interesting:
I just realize that the webmaster of the JSON data source has finally added the @context link inside the data, but only on one API :
https://beta.grottocenter.org/api/v1/massifs/333
not on the other :
https://beta.grottocenter.org/api/v1/entrances/4
and I forgot this.
So for the URL in bold, there are were 2 contexts for toRdf: one as an embedded link, and one (actually the same content but another URL) coming from Titanium by options.setExpandContext() .
The Titanium warning was written for the embedded link to:
https://ontology.uis-speleo.org/grottocenter.org_context.jsonld
returning non Content-Type ,
but the Expand Context URL :
https://github.com/jmvanel/Karstlink-ontology/raw/master/grottocenter.org_context.jsonld
says:
Content-Type: text/plain

Certainly one of the 2 contexts has priority ...

from titanium-json-ld.

OK,I'll ask my co-workers to fix the Content-Types,
but I'll use sometimes github raw URL or files for testing @context 's .

from titanium-json-ld.