Back to bug 1037753

Who When What Removed Added
Kyle Lape 2013-12-03 18:29:57 UTC Target Release --- EAP 6.2.CP0a
Version 6.2.0 6.1.1
Blocks 1027004
Weinan Li 2013-12-04 04:23:56 UTC CC weli
Kyle Lape 2013-12-06 18:31:21 UTC Blocks 1039135
Kyle Lape 2013-12-06 18:31:59 UTC Blocks 1027004
mark yarborough 2013-12-17 00:28:19 UTC Target Release EAP 6.2.CP0a EAP 6.3.0
mark yarborough 2014-01-14 09:26:25 UTC Target Release EAP 6.3.0 EAP 6.2.2
CC jawilson, myarboro
Blocks 1049365
Summary Chosen variant is not always the best match [GSS] (6.2.x needs triage) Chosen variant is not always the best match
Flags needinfo?(jawilson)
Jimmy Wilson 2014-01-27 08:04:09 UTC Flags needinfo?(jawilson)
Carlo de Wolf 2014-02-11 08:08:07 UTC Target Release EAP 6.2.2 EAP 6.3.0
CC cdewolf
Blocks 1049365
Carlo de Wolf 2014-02-11 08:08:38 UTC Blocks 1063653
Carlo de Wolf 2014-02-11 08:13:10 UTC Blocks 1063657
Carlo de Wolf 2014-02-11 08:14:26 UTC Blocks 1063657
Carlo de Wolf 2014-02-11 08:15:58 UTC Summary [GSS] (6.2.x needs triage) Chosen variant is not always the best match [GSS] (6.x needs triage) Chosen variant is not always the best match
Brad Maxwell 2014-02-20 01:32:02 UTC CC bmaxwell
mark yarborough 2014-04-07 13:45:24 UTC Status NEW ON_QA
Target Milestone --- ER1
Summary [GSS] (6.x needs triage) Chosen variant is not always the best match [GSS] (6.3) Chosen variant is not always the best match
Petr Sakař 2014-04-08 09:17:37 UTC Status ON_QA VERIFIED
Brad Maxwell 2014-04-16 20:29:02 UTC Summary [GSS] (6.3) Chosen variant is not always the best match [GSS] (6.3.0) Chosen variant is not always the best match
Scott Mumford 2014-04-24 03:38:36 UTC CC klape, smumford
Doc Text In previous versions of JBoss EAP 6, it was found that RESTEasy, while adhering to specification RFC 2616, did not always return the most appropriate media handler in instances where specificity and quality factors were equal.

For instance, when given an Accept header of <literal>application/json, */*</literal> and variant values of <literal>["application/xml","application/json"]</literal>, RESTEasy's <literal>Request.selectVariant()</literal> would choose <literal>application/xml</literal> over <literal>application/json</literal>.


....
Flags needinfo?(klape)
Scott Mumford 2014-05-06 00:28:53 UTC Docs Contact rdickens smumford
Kyle Lape 2014-06-06 18:43:47 UTC CC sgilda
Doc Text In previous versions of JBoss EAP 6, it was found that RESTEasy, while adhering to specification RFC 2616, did not always return the most appropriate media handler in instances where specificity and quality factors were equal.

For instance 		In previous versions of JBoss EAP 6, it was found that RESTEasy, while adhering to specification RFC 2616, did not always return the most appropriate media handler in instances where specificity and quality factors were equal.

For instance
Doc Text , when given an Accept header of <literal>application/json, */*</literal> and variant values of <literal>["application/xml","application/json"]</literal> , when given an Accept header of `application/json, */*` and variant values of `["application/xml","application/json"]`, RESTEasy's `Request.selectVariant()` would choose `application/xml` over `application/json`.


....
Doc Text , RESTEasy's <literal>Request.selectVariant()</literal> would choose <literal>application/xml</literal> over <literal>application/json</literal>.


....
Blocks 1105695
Kyle Lape 2014-06-06 18:46:17 UTC Blocks 1105695
John Skeoch 2014-06-18 07:21:29 UTC QA Contact psakar nobody
Kyle Lape 2014-06-24 23:50:43 UTC Doc Text In previous versions of JBoss EAP 6, it was found that RESTEasy, while adhering to specification RFC 2616, did not always return the most appropriate media handler in instances where specificity and quality factors were equal.

For instance, when given an Accept header of `application/json, */*` and variant values of `["application/xml","application/json"]`, RESTEasy's `Request.selectVariant()` would choose `application/xml` over `application/json`.


.... 		In previous versions of JBoss EAP 6, it was found that RESTEasy, while adhering to specification RFC 2616, did not always return the most appropriate media handler in instances where quality factors were equal but specificity was different.

For instance, when given an Accept header of `application/json, */*` and variant values of `["application/xml","application/json"]`, RESTEasy's `Request.selectVariant()` would choose `application/xml` over `application/json`.

The fix is to make more specific Accept header values take precedence over less specific variant matches with the same quality value (e.g. both have q=1.0 or q=0.5).
Flags needinfo?(klape)
mark yarborough 2014-06-28 15:41:28 UTC Status VERIFIED CLOSED
Resolution --- CURRENTRELEASE
Last Closed 2014-06-28 11:41:28 UTC
Scott Mumford 2014-06-29 22:22:22 UTC Doc Text In previous versions of JBoss EAP 6, it was found that RESTEasy, while adhering to specification RFC 2616, did not always return the most appropriate media handler in instances where quality factors were equal but specificity was different.

For instance, when given an Accept header of `application/json, */*` and variant values of `["application/xml","application/json"]`, RESTEasy's `Request.selectVariant()` would choose `application/xml` over `application/json`.

The fix is to make more specific Accept header values take precedence over less specific variant matches with the same quality value (e.g. both have q=1.0 or q=0.5). 		In previous versions of JBoss EAP 6, it was found that RESTEasy, while adhering to specification RFC 2616, did not always return the most appropriate media handler in instances where quality factors were equal but specificity was different.

For instance, when given an Accept header of `application/json, */*` and variant values of `["application/xml","application/json"]`, RESTEasy's `Request.selectVariant()` would choose `application/xml` over `application/json`.

In this release, specific Accept header values take precedence over less specific variant matches with the same quality value (if both have q=1.0 or q=0.5 for example).

Back to bug 1037753