It's all about the answers!

Ask a question

Wrong Content-Type Header in Response of OSLC 2.0 Queries on RTC 6.0.6

Uwe Berthold (6617) | asked Jan 23 '19, 6:04 a.m.

Hi everyone,

When querying an RTC server using OSLC 2.0, I'm getting varying values for Content-Type in the HTTP response.

Most requests return Content-Type: application/xml+rdf, for example:

However it returns Content-Type: text/xml for the services of a Service Provider (= Project Area), e.g.

The problem is that this effectively breaks OSLC Discovery when using public libraries such as Eclipse Lyo 2.4.0+, (which checks the Content-Type header more thoroughly than previous versions, therefore aborting with an IllegalArgumentException).

I would like to find out if anyone else is experiencing the same.
I believe this to be a bug in RTC and could verify it against multiple installations.

3 answers

permanent link
Jim Amsden (26837) | answered Jan 23 '19, 7:10 a.m.

 Did you set header OSLC-Core-Version to 2.0? RTC defaults to 1.0 for backward compatibility.

Uwe Berthold commented Jan 23 '19, 7:24 a.m. | edited Jan 23 '19, 7:25 a.m.

Yes I did, and the server response is correctly in OSLC 2.0 format.

These are my HTTP request headers:
    Accept: application/rdf+xml
    OSLC-Core-Version: 2.0

permanent link
Ralph Schoon (62.3k33643) | answered Jan 23 '19, 7:32 a.m.
edited Jan 23 '19, 7:33 a.m.
A quick try in 6.0.6 using Postman.

 As far as I can tell, I do not need any header information and regardless if I provide that header, the result is always the same XML file. E.g. I used postman to get to the project areas service provider document and then found

from that. I get the XML regardless of providing the headers and it seem to be in the same format. I don't see any header Content-Type: text/xml  anywhere. I think I am missing something.

Uwe Berthold commented Jan 23 '19, 7:49 a.m.

When the request header key OSLC-Core-Version is missing, or has any other value than "2.0", RTC replies with OSLC 1.x by default, so the XML root tag in above case is oslc_cm:ServiceDescriptor.

With request header key OSLC-Core-Version: 2.0, it returns OSLC 2 as expected and documented, so the root tag is rdf:RDF

So far, so good. :-)

However, the HTTP response header (for OSLC 2.0) claims the contents is text/xml (well, it is that, too...)
The response header is used by Lyo (and most certainly by other OSLC frameworks) to detect the "language" of the response in order to be able to unmarshal to the class instance in the respective language.

RTC does this very consistently, except for the ServiceProvider description.

Ralph Schoon commented Jan 23 '19, 8:14 a.m.

I did look at the response headers and the content type I see is

  • content-type →
Again Postman. I don't have time now to run OSLC4J.

Uwe Berthold commented Jan 23 '19, 8:25 a.m.

This is the response Content-Type header you get when you don't supply OSLC-Core-Version: 2.0 in the request, which is correct/expected for OSLC 1 and matches the returned XML, which is also OSLC 1 then.

Ralph Schoon commented Jan 23 '19, 8:38 a.m.

This was Postman with  

Accept: application/rdf+xml
OSLC-Core-Version: 2.0

Anyway. Maybe this is OSLC4J.

Uwe Berthold commented Jan 23 '19, 9:24 a.m.

I am using Postman as well to try things out, and I can reproduce it.

Are you sure you didn't accidentally put these parameters into the "Params" tab instead of Headers? I've fooled myself with that before once or twice...

Ralph Schoon commented Jan 23 '19, 10:12 a.m. | edited Jan 23 '19, 10:13 a.m.

This is what I see: (RTC 6.0.6, Postman embedded in Crome)


Ralph Schoon commented Jan 23 '19, 10:19 a.m. | edited Jan 23 '19, 10:21 a.m.

 What the...... Must have been a typo, I went in to make sure and now I see what you see:

This is with a valid OSLC 2 header. It disappears with a typo in the OSLC header.

What do you see in Lyo? What is the effect?

Uwe Berthold commented Jan 24 '19, 1:35 a.m. | edited Jan 24 '19, 1:39 a.m.

The actual contents (body) of the response is absolutely fine as far as I can tell.  But Lyo supports unmarshalling various content types (RDF+XML, RDF+Abbreviated XML, Turtle notation, ...) and must decide which Unmarshaller to use. It does this based on the Content-Type of the response, which is sensible in my opinion.

Previous implementations in Lyo (<=2.3.0) had a much more optimistic approach, the Unmarshaller selection was essentially an
if (contenttype == turtle) then turtleReader else defaultReader
which would fail often with cryptic errors when the response body's contents was unexpected.
Since Lyo 2.4.0, there is a white-list of supported response Content-Types, and a reader is selected on a match, else an Exception is thrown. Also, there are now separate reader implementation for the "other" types.

I can't really blame the Lyo implementation for becoming more precise, and a response Content-Type of "text/xml" is very generic after all and you can't sensibly decide anything based on that value.

showing 5 of 8 show 3 more comments

permanent link
Sudipto Sarkar (63842) | answered Jan 23 '19, 10:40 p.m.
I have faced this issue in Eclipse Lyo where the response does not content some of the tags when I parse it it XML.
I deprecated the Eclipse Lyo Maven dependency to 2.2 and its working fine as of now. 

Your answer

Register or to post your answer.