Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

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

Questions
Tags
Users
Badges
Uwe Berthold
(66●3●7) 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.

1

1 vote

3 answers
8,170 views
1 vote

3 answers

Permanent link
Jim Amsden
(293●4●7) 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.


0 votes

Comments
Uwe Berthold
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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (64.6k●3●36●49) 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.

0 votes

Comments
Uwe Berthold
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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jan 23 '19, 8:14 a.m.
I did look at the response headers and the content type I see is content-type → application/x-oslc-cm-service-description+xml;charset=UTF-8 Again Postman. I don't have time now to run OSLC4J.  

Uwe Berthold
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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER 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
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
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Jan 23 '19, 10:13 a.m.
This is what I see: (RTC 6.0.6, Postman embedded in Crome)  

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER 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
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
(63●14●43) 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. 

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 11,106
× 527
× 63

Question asked: Jan 23 '19, 6:04 a.m.

Question was seen: 8,170 times

Last updated: Jan 24 '19, 1:39 a.m.

Confirmation Cancel Confirm