Wrong Content-Type Header in Response of OSLC 2.0 Queries on RTC 6.0.6
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
Ralph Schoon (62.3k●3●36●43)
| answered Jan 23 '19, 7:32 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER 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
https://clm.example.com:9443/ccm/oslc/contexts/_6C1woKYbEeiSMJX2Iy-rvg/workitems/services.xml
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.
Comments 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.
I did look at the response headers and the content type I see is
Again Postman. I don't have time now to run OSLC4J.
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. This was Postman with
Accept: application/rdf+xml
OSLC-Core-Version: 2.0
Anyway. Maybe this is OSLC4J.
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.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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?
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
|
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.
|