Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jaxrs-dev] FW: More expressive definition of the qs value in JAX-RS
  • From: Reto Gmür <reto@xxxxxxxxxxxxxxxx>
  • Date: Mon, 14 Oct 2019 12:54:33 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=factsmission.com; dmarc=pass action=none header.from=factsmission.com; dkim=pass header.d=factsmission.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MXolE76XZZ3/Vpq1osbtlfTUG0l79j9yfyFxi8uzvOg=; b=HfY2m1qmIU/5KEar2GdCeEya3hR0R3PTzP+aBeysW35rfcB9fIaUMaLycAJmYPDc+2REjRD0wtDNEqfESv82kegUGfUeYZB1efgeSWnvqaxidp4z87PrKxqQh0Rml5iw6Ih1IbqgJIWDlVYItXsbQIrN6STYsoc05C1yTc3KouCovuZ04Rm0XBM7jsoCvjrxCY66/YA67JDVK8XynnjOLRuKSh9QDMMgJuh68bH3czHAXdMTI6cUGDZNrwvFhChul6AYgdgfYAxoF1O1sospK9YWPiDRnpGSVm4M7gJPe1DuacRZNHWOvcg8CNPObMFsiwVY6Q+JKv2HU4L4Uod1Jw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lSxIEoFAvmJIqPUugAd1SA+2LUk3FFWSnmTNnUS1IiER9txoJFbJ+xzbdOv33CJhwu0MEM7zKWJQsxcfL1DGbC/kJTauiqlkEj5R7Gej2YJX2KhwSxHoX6ReYXfEW+gU/3RuYtqK0xWWIf6NvAKs7JCS9NTUwXxqglR/2JNq0MC5WoDWqwb5odRotyktBUZz6wHyDCP/wmZ/NKJM3QqS39UHeAubMuF60e1vzvax33EoG+tzirROBGLhNFBiWdvLh+4UAyQHxFQ0WgUQT0vWqonv7uXbRLO6OdYDT4bH6miC6OdJi7YOuNZULzF3nq4Kr5VLz1ACKaaMIlQGsn9V+g==
  • Delivered-to: jaxrs-dev@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/jaxrs-dev>
  • List-help: <mailto:jaxrs-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/jaxrs-dev>, <mailto:jaxrs-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/jaxrs-dev>, <mailto:jaxrs-dev-request@eclipse.org?subject=unsubscribe>
  • Thread-index: AdWCjZ2SGNsU7HwiSXuCwLXX7pQ+8g==
  • Thread-topic: More expressive definition of the qs value in JAX-RS

Hello

 

I’m not sure if my email to jaxrs-spec@xxxxxxxxxxxxxxxx was ever read by anyone. Thankfully Ron Sigal pointed me here discussing a RestEasy PR (https://github.com/resteasy/Resteasy/pull/2152#issuecomment-541206591).

 

The improvement to the JAX-RS spec that I would like to suggest is part of a Pull Request I’ve made to the jax-rs/spec project in GitHub: https://github.com/jax-rs/spec/pull/6 but that projects seems to have been inactive since the release of JAX-RS 2.1.

 

So I hope to get some feedback on the proposed changes here and to learn if and how the JAX-RS spec is further developed.

 

Regards,

Reto

 

 

 

From: Reto Gmür
Sent: Sunday, September 1, 2019 8:23 PM
To: jaxrs-spec@xxxxxxxxxxxxxxxx
Subject: More expressive definition of the qs value

 

Hello

 

The HTTP RFC 7231 defines the q-value as “relative ‘weight’ to the preference”.  The two examples provided in section 5.3.2 imply two different interpretations of what that means. The first interpretation the weight is relative to the quality in which the server can provide a specified format while in the second example the weight only indicates a relative preference. The JAX-RS specification interprets the q value and defines the qs value only as a sorting key to determine the preference over other formats in the same set.

 

I argue that following example included in RFC 7231 provides the better interpretation of the q-value and this would suggest a more powerful definition of the qs value:

 

       Accept: audio/*; q=0.2, audio/basic

 

   is interpreted as "I prefer audio/basic, but send me any audio type

   if it is the best available after an 80% markdown in quality".

 

By this interpretation a definition of qs would suggest itself by which qs is not merely a tertiary sorting criteria but an indicator of the quality in which a response in that format can be produced. So for example if the server can produce audio/basic; qs=0.1 and audio/extended; qs=1 the server should return audio/extended as after an 80% markdown in quality it is the best available format.

 

To achieve this, in Section 3.8  step 7 the secondary key for sorting M could be defined as the product of q and qs and no tertiary key would be needed.

 

Regards,

Reto

 

 

Back to the top