11

Hi all I've been examining Chrome's request headers whenever we type a URL into the address bar and I was wondering what exactly does it mean by these headers:

Accept: application/xml;q=0.9
Accept-Charset: utf-8;q=0.7
Accept-Language: en;q=0.8

This thread says it's the quality factor, so Chrome is saying it is accepting >=90% quality application/xml, >=70% quality UTF-8, and >=80% english language.

What exactly does 90% quality application/xml, 70% quality UTF-8, and 80% english language mean here?

Community
  • 1
  • 1
Pacerier
  • 86,231
  • 106
  • 366
  • 634
  • 2
    The answer you're linking to seems to explain it pretty well: `"Accept: audio/*; q=0.2, audio/basic" SHOULD be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in quality."` It shows the client's preference for different types. If there's only one, it's arguably somewhat pointless. – deceze Jan 18 '12 at 07:56

2 Answers2

3

The name relative quality factor is a little bit misleading.
I think it's being used to order the preference of the values for the header just like the docs say:

A more elaborate example is

   Accept: text/plain; q=0.5, text/html,
           text/x-dvi; q=0.8, text/x-c

Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity."

In your example it's easy to decide, because each header has only one value.

matino
  • 17,199
  • 8
  • 49
  • 58
  • So does that mean that for your example, `text/plain;q=0.0001, text/html, text/x-dvi;q=0.0002, text/x-c` is equally equivalent since it's *relative* ? Or am I misunderstanding something here? – Pacerier Jan 18 '12 at 08:08
  • 1
    Note that you can't have more than three digits after the decimal in qvalues. Also, the accepted answers seems wrong. It can't have to do with "percentage of characters" or such. It seems to be nothing more than a way of ranking preferences and specific numbers mean nothing more than whether they are bigger or smaller than other numbers. – BPS Mar 28 '12 at 13:46
  • As per the 2014 https://tools.ietf.org/html/rfc7231#section-5.3.2 , the q-value has a specific meaning beyond mere sorting. "The example 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"." – Reto Gmür Sep 01 '19 at 16:17
3

These headers are explained in RFC 2616.

Accept-Charset: utf-8;q=0.7

The key to understanding this line is that ISO-8859-1 is accepted by default even if it isn't mentioned. The header says "I want ISO-8859-1, but I'll accept UTF-8 if using ISO-8859-1 would degrade the quality of the object being sent by more than 30%." I'd take this to mean that if 30% of the characters won't fit into ISO-8859-1, then use UTF-8, but the standard doesn't seem to require this interpretation.

For the other examples you gave the quality factors are no-ops because there are no alternatives or defaults to preempt the definition of what's accepted.

Kyle Jones
  • 5,492
  • 1
  • 21
  • 30