More powerful handling of qs-values

[retog]

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 is defined as the product of q and qs and q is used as tertiary key, analogous changes have been made in section 3.7.2.

[arucard21]

This is an interesting approach but I noticed some problems with it. I hope you don't mind me providing feedback.

Defining qs as "an indicator of the quality in which a response in that format can be produced" means that the server would have to determine how well it can produce each format. The format here is the media type and any response for that media type must adhere to the media type specification. So I can't see a scale of how well a server can produce each media type.

So then this qs weight essentially becomes an evaluation of the media type itself. This seems to be the main improvement of this approach. It allows the server to override the preferences of the client if a better alternative can be provided (one that is still considered acceptable by the client).

While this indeed provides the server with more power, it does so at the expense of the client. In the provided example, the client essentially says:

I strongly prefer audio/basic but I'll take other audio types even though I dislike them

With this suggested approach, the server would respond like this:

You prefer audio/basic. I have it but I think audio/extended is much better and it is something you can accept. Since I like audio/basic (qs=0.1) less than you like other audio types (q=0.2), I'm going to give you audio/extended.

This makes it hard for clients to get any kind of expectation of what they will actually get. This now depends on the qs values used by the server which are generally not known to the client.

Another problem with overriding the client's explicit preferences is that the server actually can't make a better judgement than the client about this since the server doesn't know why the client has those preferences. In the same example, the server may indicate that audio/extended is objectively better sounding audio than audio/basic. But let's say the client is on a mobile or embedded device and prefers audio/basic because it's the most power-efficient to use. Then using audio/extended is actually not that good for the client. Of course, the client wants to be able to play the audio even if it has to be less power-efficient so that's why it'll still accept other audio types, if necessary.