HTTP Accept "level"?

Question

I have been reading up on the HTTP/1.1 headers and in some of the sample headers in section 14.1 (Accept) they use accept-extensions (I believe that is what they are) called level=1, level=2, etc.

The problem I am having is that they use these level=X things as if it should be obvious what they do. Is the document just poor at explaining it or am I missing something?

Thanks.

Answer 1

...A Couple Years Later

The user TomWardrop points out that (from comments to this answer):

It use to be part of the text/html media type specification to indicate what version of HTML you wanted, but is wasn't used much (if at all), so it was dropped. Refer to ietf.org/rfc/rfc2854.txt.

Excerpt from the RFC:

Note that [HTML20] included an optional "level" parameter; in practice, this parameter was never used and has been removed from this specification. [HTML30] also suggested a "version" parameter; in practice, this parameter also was never used and has been removed from this specification.

This appears to be the best answer so far.

I am leaving the original answer below for posterity.

---

Summary

It appears from looking through RFC-2616 (Request For Comments) over at IETF and W3C, as well as websites elsewhere on the internet, that the level extension is not very well documented or explained. It also does not appear to be in use in headers by anyone, suggesting that it can probably be ignored.

The RFCs

In the RFCs the level parameter is seen in a few examples, but it is never mentioned or clearly expressed exactly what role it plays.

level is used in an example about precedence:

Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence. For example,

    Accept: text/*, text/html, text/html;level=1, */*

have the following precedence:

    1) text/html;level=1
    2) text/html
    3) text/*
    4) */*

Source: IEFT RFC-2616 p.100 and W3C RFC2616 section "14.1 Accept"

Seeing the difference between how the types are ordered in the two examples, it looks like text/html;level=1 has greater precedence than text/html, meaning that the level extension must give it that precedence. The last two are obviously ordered further, according to declining specificity.

Now this brings up the quality factor, q. It is explained quite well in the RFCs. It can be anything between 0 and 1. The bigger the value the more precedence the type has. The RFC has an example using both q and level:

The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type. For example,

    Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
            text/html;level=2;q=0.4, */*;q=0.5

would cause the following values to be associated:

    text/html;level=1         = 1
    text/html                 = 0.7
    text/plain                = 0.3
    
    image/jpeg                = 0.5
    text/html;level=2         = 0.4
    text/html;level=3         = 0.7

Source: IEFT RFC-2616 p.100 and W3C RFC2616 section "14.1 Accept"

From this it appears that level's value is used in decreasing precedence (1 has highest precedence, 2 second highest, etc.). That makes sense, but when taken together with the Accept: header it makes no sense at all:

1. First, the q parameters have magically disappeared from the types, in the associations (below). It is like the author assumed that it is obvious why they have been omitted, but forgot to tell us why it is obvious.

2. Second, the types in the Accept: header, and the types shown in the associations (below), are not the same types. E.g the image/jpeg type is never mentioned in the header, and the text/* type is missing from the associations.

I am at a loss to explain what it all means.

Zend Framework Discussion

On an answer to a question asking about the level parameter there is some interesting stuff.

q and level compliment each other

[...] The q-factor is the one most looked at. However, you can also specify a "level", and these CAN also act like priorities, but operate in the order of decreasing precedence (i.e., level 1 is higher priority than level 2). The examples they have in the spec are contrived, and, tbh, confusing at best [...]

The q parameter is what you should use, and the level parameter can be used. Okay, but it still does not clear up exactly what it does, and how it is supposed to affect the priorities of types.

Used for supported type/spec version

Another documented use case for the "level" is to indicate the _version_ of the type. As an example, a "level 1" might indicate the first version of that spec available. In such cases, it wouldn't be a priority, but instead a _descriptor_ [...]

So, a way of indicating what version of the type is supported. Now, this actually makes more sense:

text/html;level=5;q=1
text/html;level=4.01;q=0.9
; Etc.

Somehow I doubt level was supposed to be used for this, however. If it was then it would probably have been called something more descriptive, such as version, or simply v (like q).

Conflicting meanings

Unfortunately, the "level" selector has conflicting meanings, so I'm not 100% sure we should support it by default; "q", on the other hand, is well documented.

Yeah. Conflicting meanings and not very well documented. The level property has very little going for it.

Other stuff I found

Looking for questions/answers elsewhere on the Internet I found:

• A seriously old-school document that does not mention level at all. It actually mentions two other ones, mxs and mxb.
• A Moz Dev page listing common Accept headers from various browsers. Nowhere is level used. In fact, I have never seen it used outside the RFCs.

Conclusion

In conclusion I think it is safe to say that level is a waste of time. It is poorly documented, not used much in practice (if used at all), and it is more confusing than it is worth.

Answer 2

"level" is just an example for a media type parameter. It's not involved in computing the preference.

(The relevant spec nowadays is http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-26.html#header.accept)

Answer 3

Expanding on Julian Reschke's correct answer a little. The answer mentions "media type parameter" which comes directly from the specification:

Accept = #( media-range [ accept-params ] )

     media-range    = ( "*/*" / ( type "/" "*" ) / ( type "/" subtype )) *( OWS ";" OWS parameter )
     accept-params  = weight *( accept-ext )
     accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]

Where parameter is defined as:

parameter = token "=" ( token / quoted-string )

That is, a name/value pair (see token). So, in the examples, "level=1" is just an example of a legal "parameter". In that sense, there's nothing really special about it. If you take the time to parse the Backus-Naur of the definition, you'll see that, in all of the examples, the "level=x" must be a media-type parameter.

With regard to why the example specifically uses "level", I think the "level" in the HTTP spec examples refers to HTML levels. In all of the examples, level modifies the text/html media type. The best definition I've found for HTML levels is:

"There are four official levels [0-4], or versions of HTML conformance. Each encompasses a set of tags and higher levels include tags from all those below it."

http://scholar.lib.vt.edu/reports/soasis-slides/slide4.html

I.e., a request could use Accept to ask for a lower level of HTML if it wanted a subset of HTML elements/attributes. As an example, HTML level 0 defines the DOCTYPE element, but does not define the "Version" attribute until level 3; so that HTML levels 0-2 would/should not contain a Version attribute in a <!DOCTYPE> declaration.

http://www.december.com/html/spec/level0.html

http://www.december.com/html/spec/level3.html

"level" seems like an old aspect/feature of HTML. I can find very few references to it, none of them are clear (e.g., is there a difference between HTML level and major version?), and most of those I can find are old. However, the latest Apache httpd server docs still say they support "level" in content negotiation, and suggest that it may be synonymous with version, at least in that implementation:

"4. Select the variants with the highest 'level' media parameter (used to give the version of text/html media types)."

Note that the IANA registry doesn't mention anything about "level" as a text/html parameter. If nothing else, that says to me: "don't use it."

Interestingly, the DOM specification still uses the word "level".

http://www.w3.org/TR/DOM-Level-2-HTML/

http://www.w3.org/TR/DOM-Level-3-Core/

etc..