Bug 862781

Summary:	[RFE] [RESTAPI]: missing encoding charset in api json responses
Product:	[Retired] oVirt	Reporter:	Gal Leibovici <gleibovi>
Component:	ovirt-engine-api	Assignee:	Ori Liel <oliel>
Status:	CLOSED WONTFIX	QA Contact:	bugs <bugs>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	3.5	CC:	acathrow, bazulay, ecohen, gklein, iheim, jkt, juan.hernandez, pstehlik, Rhev-m-bugs, srevivo, yeylon
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	3.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-02-26 13:04:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gal Leibovici 2012-10-03 14:14:00 UTC

API responses are missing encoding info in HTTP header Content-Type.
It should have a charset value with the encoding of the response body.

For Example: Content-Type: "application/xml; charset=UTF-8"

Comment 4 Juan Hernández 2013-10-10 16:34:37 UTC

I submitted a patch that modifies the application so that it will add the charset to the Content-Type header:

  http://gerrit.ovirt.org/20104

The result is something like this:

  HTTP/1.1 200 OK
  Date: Thu, 10 Oct 2013 15:37:34 GMT
  Server: Apache/2.4.6 (Fedora) OpenSSL/1.0.1e-fips
  Pragma: No-cache
  Cache-Control: no-cache 
  Expires: Thu, 01 Jan 1970 01:00:00 CET
  Content-Type: application/json;charset=UTF-8
  Vary: Accept-Encoding
  Transfer-Encoding: chunked

However it isn't clear to me if we want to do this for JSON (as in the subject of the bug) or for XML (as in the initial descrition) or for both.

Comment 8 Juan Hernández 2014-02-17 16:51:31 UTC

The solution in comment 4 has been rejected.

Comment 9 Ori Liel 2014-02-26 13:04:41 UTC

Resteasy does not provide a way to dynamically set charset in the response. Only 'hard-coded' solutions seem possible, and since a hard-coded solution has already been rejected (http://gerrit.ovirt.org/20104), we're stuck. It seems not worth the effort at this point.