- From: Daurnimator <quae@daurnimator.com>
- Date: Wed, 30 Nov 2016 13:47:17 +1100
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 31 October 2016 at 12: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 > > Don't forget to disallow anything with q=0. e.g. you might see: Accept: image/*, image/jpeg; q=0 If the client wants an image format that is *not* a jpeg.
Received on Wednesday, 30 November 2016 02:47:58 UTC