- From: Samuel Williams <space.ship.traveller@gmail.com>
- Date: Mon, 31 Oct 2016 14:49:21 +1300
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
Thanks Amos, yes, that's exactly how it works in the code. But thanks for clarifying it. The reason why I used the word computed is because it's not a direct 1-1 association. If you want to find the q value for image/jpeg, you need to first see, is there image/jpeg? no. Is there image/*? no. Is there */*? Yes. To me, this is a computation, not simply an association. On 31 October 2016 at 14:29, Amos Jeffries <squid3@treenet.co.nz> wrote: > On 31/10/2016 12:15 a.m., Samuel Williams wrote: >> Thanks Julian, yes I wondered if that was how it was being explained. >> It might be the wording of the sentence preceding the table: >> >>> would cause the following values to be associated: >> >> It might be clearer if it were "could be used to compute the following >> quality values:" >> > > It is not computing quality values. The q values are provided by the > client. It is simply associating those q= values with the possible > response types. > > Like so: > 1) take the request Accept list > 2a) sort by q= value > 2b) drop explicit types that cannot be produced (ie xml/tar) > 3) output the response for type at the front of the list > > > If you are writing a client to produce Accept lists, then you should do > the sorting step when generating the request so as to get faster > responses from the server. > > Amos > >
Received on Monday, 31 October 2016 01:49:58 UTC