Bug 1319553 - [GSS](6.3.z) Response header for kie-server call always returns application/xml
Summary: [GSS](6.3.z) Response header for kie-server call always returns application/xml
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Kie-Server
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Edson Tirelli
QA Contact: Karel Suta
URL:
Whiteboard:
Depends On: 1319552
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-21 02:36 UTC by Alessandro Lazarotti
Modified: 2020-03-27 20:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1319552
Environment:
Last Closed: 2020-03-27 20:11:16 UTC
Type: Bug


Attachments (Terms of Use)

Description Alessandro Lazarotti 2016-03-21 02:36:04 UTC
+++ This bug was initially created as a clone of Bug #1319552 +++

Description of problem:
It does not matter is a request is done using application/json, the response always returns application/xml in the header. The payload content is correct.


Steps to Reproduce:
1. Send a request to kie-server to fire-all-rules with application/json in the header

Actual results:
The response header has application/xml instead of application/json

Expected results:
application/json in the header

Comment 3 Maciej Swiderski 2016-04-07 09:13:49 UTC
headers are controlled based on given Accept request header as it's calculated based on variant sent on the response object. So make sure you instruct what is accepted content type by the client by setting Accept header:

Accept = application/json

once you set the expectations server will respond with proper content type set on response.

I don't think there is anything to do in the code if client follows HTTP communication best practice.

Comment 5 Alessandro Lazarotti 2016-04-18 21:47:56 UTC
Hi Maciej,
I see Accept as a header to define which kind of medias are acceptable in the response content, a way to restrict and filter the content that we can consume:

"The Accept request-header field *can be used* to specify certain media types which are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types" (https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html)

If customer set json in Accept, it should only consume json content-type ad we should send that in the payload - that is fine.
if customer does not set any accept, it may be receive any content-type - but the content-type header should have the vale correct with what is delivered.

We are sending in response the content-type header with a value different than that really sent in the response payload. The content sent is json, but the header says xml. 

Another example, if we set as Accept "application/json,application/xml" (customer client can handle xml or json) and we set X-KIE-ContentType as "JSON" the server will reply with a json content but with content-type as xml, which is incorrect.

I hope this clarify the issue.

Comment 6 Karel Suta 2016-04-19 07:40:21 UTC
Just noticed one thing, if I set Content-Type header to application/xml, Accept header to application/json and send request in XML format, Kie server will throw marshalling error.
It seems to be caused by Kie server unmarshalling request content according to format defined in Accept header.

Comment 7 Maciej Swiderski 2016-04-20 13:48:35 UTC
since this has not be done on any of the branches at the moment - PR is on master I'd opt to move it out from the coming patch to make sure we don't introduce any regressions because of it

Thoughts?

Comment 8 Alessandro Lazarotti 2016-04-22 19:09:13 UTC
That is fine Maciej,
Let's remove it from 6.2.z  and change it to 6.3.z (Update 1)

The issue is not critical and Accept works for users that needs to receive a correct content-type header in response. For 6.3 udpate 1 the expectation is to get a fix for the scenario where no Accept is sent but the content provided is not equal to the content-type header - or if two Accepts are sent, the return should be consistent with the content-type header.

Comment 10 Maciej Swiderski 2016-04-25 15:54:05 UTC
fix has been merged to master so for the rollup patch it needs to be back ported once approved

droolsjbpm-integration
master:
https://github.com/droolsjbpm/droolsjbpm-integration/commit/2d791924c265edf1bba78add9f3fbccf332d8431


Note You need to log in before you can comment on or make changes to this bug.