• (cs)

    The idea is list preferred MIME-Types earlier in the list.

    So isn't this bit backwards?

    <font face="courier new">application/xhtml+xml, application/vnd.wap.xhtml+xml</font>

  • (cs)

    Isn't it just better to be safe than sorry?  Just in case

    -- thick sarcasm --

  • WTFery (unregistered) in reply to richleick

    hmm..

     you guys must be running out of stuff there.

    what you need is to crack open some more vb jokes, oops I mean source.

  • (cs) in reply to richleick

    What if * gets redefined?

  • ak (unregistered)

    Yup, the mobile phone industry creates the most braindead software you can imagine, and a lot of mobile phones have bugs that simply make you shake your head.

    A good example is the SonyEricsson P-800: if you want to download a wallpaper via a WAP Push message, the P-800 will fail to display it after downloading when the URL isn't static or doesn't end in the filename extension that fits the file format (e.g. when you send a JPEG file, the extension must be .jpg), and it completely ignores the Content-Type header. argl

    There are many more stories to tell, but if you continued, it would remind me of the old horror stories and make me puke.

  • (cs) 
    // need to set the mime type if it hasn't been set yet, we'll accept all mime types
    // because there should be no bias.
  • (cs)

    I think he's right - it's because they charge by the kilobyte. Ouch - around 1275 bytes just for one mostly worthless header. How much does that cost per request?

  • David (unregistered) in reply to Mung Kee
    Mung Kee:
    // need to set the mime type if it hasn't been set yet, we'll accept all mime types
    // because there should be no bias.

    Heh.

  • khoker (unregistered)

    Hold on a second. Are customers responsible for paying upstream bandwidth as well as downstream? I might be wearing a tinfoil hat, but could this be a way to get an extra $0.02 for every request made from the phone?

  • (cs)

    I wonder whether there is a switch-statement involved somewhere shiver

    -- i'm a .sig when i'm big.

  • Marc (unregistered) in reply to ak
    Anonymous:
    Yup, the mobile phone industry creates the most braindead software you can imagine, and a lot of mobile phones have bugs that simply make you shake your head.
     
    My Kyocera can play every tone on earth except the standard telephone ring! Virgin Mobile refuses to make a teelphone ring available on their web site for free to fix this since they couldn't do this without making it available to everybody.
     
    M.
  • (cs) in reply to Marc
    Anonymous:
    Anonymous:
    Yup, the mobile phone industry creates the most braindead software you can imagine, and a lot of mobile phones have bugs that simply make you shake your head.
     
    My Kyocera can play every tone on earth except the standard telephone ring! Virgin Mobile refuses to make a teelphone ring available on their web site for free to fix this since they couldn't do this without making it available to everybody.
     
    M.


    ... and Lord knows you wouldn't want hundreds of thousands of people wandering around with telephones that sound like telephones.
  • (cs)

    As someone previously pointed out, the Accept list is supposed to list alternative MIME types in order of preference.

    I find it very interesting that on this particular request, the phone most strongly desires a CSS stylesheet file; however, if you don't have one readily available, a JPEG or a MIDI will do just fine.

    What are they planning to do? OCR a screenshot of a CSS file, or (failing that) use voice recognition software to grok a recording of someone reading a CSS stylesheet aloud?

  • (cs)

    but... wouldn't */* be equal to 1?  (Maybe we need the AreEqual function from a couple of days ago to find out...)

    WTF

     

  • A Nonny Mouse (unregistered) in reply to Stan Rogers
    Stan Rogers:
    Anonymous:
    Anonymous:
    Yup, the mobile phone industry creates the most braindead software you can imagine, and a lot of mobile phones have bugs that simply make you shake your head.
     
    My Kyocera can play every tone on earth except the standard telephone ring! Virgin Mobile refuses to make a teelphone ring available on their web site for free to fix this since they couldn't do this without making it available to everybody.
     
    M.



    ... and Lord knows you wouldn't want hundreds of thousands of people wandering around with telephones that sound like telephones.

     

    I used to think it would be nice to hear mobiles that sounded like phones used to in the good old days. Then one of my colleagues got a mobile that is just a ringing noise. It goes off about 3 times an hour all day. I've gone right off the idea. I also may have to kill him shortly.

     

  • David P. Murphy (unregistered) in reply to makomk
    makomk:
    I think he's right - it's because they charge by the kilobyte. Ouch - around 1275 bytes just for one mostly worthless header. How much does *that* cost per request?


    I agree with your cynicism; however, I'm not sure why "Accept: */*" is not considered "entirely worthless".


    ok
    dpm
  • (cs) in reply to jvancil
    jvancil:

    but... wouldn't */* be equal to 1?  (Maybe we need the AreEqual function from a couple of days ago to find out...)

    WTF

     

    Not if *=0 (hey that almost looks like the expression on my face when I saw the WTF). 0/0 is undefined. You can sometimes work out a finite limit as * approaches 0, but the answer depends on exactly how * does so. Which makes / a nice shorthand for '...and everything else' since it can evaluate to pretty much whatever you want it to. I've never seen it equal a MIME type, but I suppose if they were all just variable names it would work out.

  • (cs) in reply to Oliver Klozoff
    Oliver Klozoff:
    As someone previously pointed out, the Accept list is supposed to list alternative MIME types in order of preference. I find it very interesting that on this particular request, the phone most strongly desires a CSS stylesheet file; however, if you don't have one readily available, a JPEG or a MIDI will do just fine. What are they planning to do? OCR a screenshot of a CSS file, or (failing that) use voice recognition software to grok a recording of someone reading a CSS stylesheet aloud?

    No, no, that's not it. It's a MIDI file. AFAIK, you can't get voice into that, unless they think someone is going to code it in as instrument patches or something...

    No, I bet they generate the CSS by assigning a letter value to each note. ABCDEFG, and I bet the half-tones are assigned punctuation like <>.";:* so people can actually do something with their CSS.

  • (cs) in reply to A Nonny Mouse

    Anonymous said: I used to think it would be nice to hear mobiles that sounded like phones used to in the good old days. Then one of my colleagues got a mobile that is just a ringing noise. It goes off about 3 times an hour all day. I've gone right off the idea. I also may have to kill him shortly.

    I bet you would have already killed him if the phone played some annoying tune, like that bananaphone song for instance.

    My phone moofs.

  • (cs) in reply to Oliver Klozoff
    Oliver Klozoff:
    As someone previously pointed out, the Accept list is supposed to list alternative MIME types in order of preference.

    Forgive me, but this is incorrect.
    ftp://ftp.isi.edu/in-notes/rfc2616.txt (scroll to page 100)

    The definition of the Accept HTTP/1.1 header says that the q parameter specifies the preference, and that it defaults to 1.0. Thus, if a media type has no q parameter, its preference is 1.0, no matter where in the list it occurs. There is an example that explicitely says so.
    From this point of view, the WTF becomes even greater, because */* has exactly the same preference as all other types. In other words, application/vnd.microsoft.excel is just as fine as text/html.

    I have a vague memory, however, of IE not honouring the q= system correctly and sending an unqualified list in order of preference. So servers (esp. IIS) might interpret this phone's header as intended.
  • Kevin (unregistered) in reply to CornedBee
    CornedBee:
    Oliver Klozoff:
    As someone previously pointed out, the Accept list is supposed to list alternative MIME types in order of preference.

    Forgive me, but this is incorrect.
    ftp://ftp.isi.edu/in-notes/rfc2616.txt (scroll to page 100)

    The definition of the Accept HTTP/1.1 header says that the q parameter specifies the preference, and that it defaults to 1.0. Thus, if a media type has no q parameter, its preference is 1.0, no matter where in the list it occurs. There is an example that explicitely says so.
    From this point of view, the WTF becomes even greater, because */* has exactly the same preference as all other types. In other words, application/vnd.microsoft.excel is just as fine as text/html.

    I have a vague memory, however, of IE not honouring the q= system correctly and sending an unqualified list in order of preference. So servers (esp. IIS) might interpret this phone's header as intended.


    The q is for quality, 0 to 1.  Full quality, 1, is the default.  The value was to request lower quality videos or audio samples.  Thus, preference is given to types that will be of full quality.

    The order of preference is determined, first by quality, second by specificity (text/html takes precendence over text/*), and third by order they are listed.  In other words, if all types are specific and q= is never used, the first one supported should be selected.

    Very few programmes use the q= value these days.  It even says so on page 99 of the RFC.  Right around the "due to historical practice".
  • JoeJoe (unregistered)

    ININITRY PLUS ONE!!!

  • Random Passerby (unregistered) in reply to Kevin
    Anonymous:
    The q is for quality, 0 to 1.  Full quality, 1, is the default.  The value was to request lower quality videos or audio samples.  Thus, preference is given to types that will be of full quality.
    That's completely wrong.  Quoted from the RFC: "Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (section 3.9). The default value is q=1."  In other words, what is referred to as "quality" is actually an order of preference.

    Anonymous:
    The order of preference is determined, first by quality, second by specificity (text/html takes precendence over text/*), and third by order they are listed.  In other words, if all types are specific and q= is never used, the first one supported should be selected.
    While this may be true in practice (I'm uncertain), it's definitely not how programs are supposed to behave according to the RFC.  (You're right about the quality and specificity ordering, but listing order should not be a factor.)

    In this example, all the items have the same quality level (1), and all but the last (*/*) have equal specificity.  So it's basically saying that it prefers *any* one of the listed media types rather than some random other thing, but if there's no other option then it'll just take what its given.

    It's still kinda silly, though (unless its being used as a way to charge more), because only in unbelievably rare cases are servers actually configured with multiple resource types available from a single URL.
  • (cs) in reply to Random Passerby
    Anonymous:
    Anonymous:
    The q is for quality, 0 to 1.  Full quality, 1, is the default.  The value was to request lower quality videos or audio samples.  Thus, preference is given to types that will be of full quality.
    That's completely wrong.  Quoted from the RFC: "Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (section 3.9). The default value is q=1."  In other words, what is referred to as "quality" is actually an order of preference.

    Anonymous:
    The order of preference is determined, first by quality, second by specificity (text/html takes precendence over text/*), and third by order they are listed.  In other words, if all types are specific and q= is never used, the first one supported should be selected.
    While this may be true in practice (I'm uncertain), it's definitely not how programs are supposed to behave according to the RFC.  (You're right about the quality and specificity ordering, but listing order should not be a factor.)

    In this example, all the items have the same quality level (1), and all but the last (*/*) have equal specificity.  So it's basically saying that it prefers *any* one of the listed media types rather than some random other thing, but if there's no other option then it'll just take what its given.

    It's still kinda silly, though (unless its being used as a way to charge more), because only in unbelievably rare cases are servers actually configured with multiple resource types available from a single URL.

    It's theoretically possible to have a single url feed html, text, rss, random xml, and anything else off a single url, and I've seen it done, but the incompatibility factor is so high that it's always easiler to stick to one-name-one-resource or url query string. That was one of the places the writers of the RFC had a bit too much faith in the implementors.

    Not sure why more browsers don't just have Accept: */*, it's not like single-url is going to come into style soon, and they're going to turn down whatever's given to them.
  • Calvin M Spealman (unregistered)

    So I'm paying at least two cents for every request, before I even start downloading anything? Wow, I really am getting ripped off.

  • Ilpalazzo-sama (unregistered) in reply to chb

    You just KNOW the code behind that looks something like this:

    string strAccept = "Accept: ";

for (float lngCount = 1; lngCount < g_NumTypes; lngCount++) {
   switch (lngCount) {
      case 1:
         strAccept = strAccept + "text/css";
         if (lngCount < g_NumTypes) strAccept = strAccept + ", ";
         break;
      case 1:
         strAccept = strAccept + "application/vnd.wap.wmlscriptc";
         if (lngCount < g_NumTypes) strAccept = strAccept + ", ";
         break;

      // and so on ...

      default:
         strAccept = strAccept + "*/*";
         if (lngCount < g_NumTypes) strAccept = strAccept + ", ";
         break;
   }
}
  • Ilpalazzo-sama (unregistered) in reply to Ilpalazzo-sama

    Stupid forum software...
    what I was trying to say was:

    string strAccept = "Accept: ";
for (float lngCount = 1; lngCount < g_NumTypes; lngCount++) {
   switch (lngCount) {
      case 1:
         strAccept = strAccept + "text/css";
         if (lngCount < g_NumTypes) strAccept = strAccept + ", ";
         break;
      case 2:
         strAccept = strAccept + "application/vnd.wap.wmlscriptc";
         if (lngCount < g_NumTypes) strAccept = strAccept + ", ";
         break;

      // and so on ...

      default:
         strAccept = strAccept + "*/*";
         if (lngCount < g_NumTypes) strAccept = strAccept + ", ";
         break;
   }
}
  • Ilpalazzo-sama (unregistered) in reply to Ilpalazzo-sama

    Okay, I give up.

  • Welcome To The Machine (unregistered)
    Alex Papadimoulis:

    they were all a bit mystified at why a mobile phone would send such huge request headers ...

    That's BRILLANT!

    Stupid mobile phone companies - and yes they do charge for upstream as well as downstream, I agree this may be a combination of lazy coding, idiotic overkill and a money making scheme.

  • (cs) in reply to Ilpalazzo-sama

    Apparently this wonderful HTML enditor does not escape angled braces in code blocks. Let me try:

    Anonymous:
    You just KNOW the code behind that looks something like this:

    string strAccept = "Accept: ";

    for (float lngCount = 1; lngCount &lt; g_NumTypes; lngCount++) {
       switch (lngCount) {
          case 1:
             strAccept = strAccept + "text/css";
             if (lngCount &lt; g_NumTypes) strAccept = strAccept + ", ";
             break;
          case 1:
             strAccept = strAccept + "application/vnd.wap.wmlscriptc";
             if (lngCount &lt; g_NumTypes) strAccept = strAccept + ", ";
             break;

          // and so on ...

          default:
             strAccept = strAccept + "*/*";
             if (lngCount &lt; g_NumTypes) strAccept = strAccept + ", ";
             break;
       }
    }
  • Asd (unregistered) in reply to brazzy

    Pah, this is the least of the problems with mobile phone browsers. I can never understand why some phones can't use a linked css file even though other phones from the same company with the same OS do. Pretty much every mobile phone browser is broken in some way or other e.g. nested divs, table support, css support.

  • (cs) in reply to Asd
    Anonymous:
    Pah, this is the least of the problems with mobile phone browsers. I can never understand why some phones can't use a linked css file even though other phones from the same company with the same OS do.

    Probably a different version of the browser.

    Anonymous:

    Pretty much every mobile phone browser is broken in some way or other e.g. nested divs, table support, css support.


    No surprise. Rendering webpages is extremely difficult to get right due to the complex mess of the standards, their various extensions and lack of most pages to actually confirm to any of them. It took the PC browser makers 10 years to get it mostly right.  And the phone makers can't use that code because it's way too bloated to run on their limited-resource devices.
  • Ilpalazzo-sama (unregistered) in reply to brazzy

    Actually, it did escape the brackets correctly when I first typed my text, but then I failed the Captcha test and apparently when the forum software posts the message back for a retry it seems to unescape them and then forgets to escape them on the final submission. The same happened both times I tried, even though I was pretty sure I had entered the right word and no typos...

    PS: First captcha attempt failed again just now. 100% certain I entered the correct word. Looks like a bug to me.

    PPS: Second try failed, too. Maybe it's a timeout issue? Since the captcha is generated when the message edit form is displayed, if you take too long to write or edit the message, it's expired by the time you get to click on "post" ...

  • Xander Lebrun (unregistered) in reply to NSCoder
    NSCoder:

    Not if *=0 (hey that almost looks like the expression on my face when I saw the WTF). 0/0 is undefined. You can sometimes work out a finite limit as * approaches 0, but the answer depends on exactly how * does so. Which makes */* a nice shorthand for '...and everything else' since it can evaluate to pretty much whatever you want it to. I've never seen it equal a MIME type, but I suppose if they were all just variable names it would work out.


    But if * is a non-zero element of a field then */* will equal 1, by definition of division. So how can you have any finite limit of */*s that doesn't equal 1? Or were you thinking of taking limits of a/b as a->b?
  • me (unregistered)

    You're sure that you didn't forgot anything in this way :D

  • terrbear (unregistered) in reply to me

    YOU FORGOT POLAND!

  • imajes (unregistered)

    a certain OS X browser used to do this... and it frequently tripped certain tripwires... I ended up talking to the CTO about how that was a really pointless thing to do. :)

  • me (unregistered)

    how big is your freakin' monitor anway? this page is double the width of mine...

  • Eric (unregistered) in reply to me

    Yeah, can you guys try to do a better job of making these posts Firefox (Gecko, actually) freindly? Many of them require lots of horizontal scrolling which is a big no-no in web design.

  • Kevin (unregistered) in reply to Random Passerby
    Anonymous:
    Anonymous:
    The q is for quality, 0 to 1.  Full quality, 1, is the default.  The value was to request lower quality videos or audio samples.  Thus, preference is given to types that will be of full quality.
    That's completely wrong.  Quoted from the RFC: "Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (section 3.9). The default value is q=1."  In other words, what is referred to as "quality" is actually an order of preference.


    You only read part of that section which states that quality affects preference. But there is a reason why. Quality degradation is undesirable, but generally unavoidable when converting formats, language, etc.

    From page 100:

       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."


    This means "if you cannot give me an audio/basic file, choose whatever format you can give with no more than 80% degradation". Obviously 0% (qvalue of 1) is most desirable.

    Check out this post of notes from an IETF meeting that discusses this very topic in more comprehensible language:

    http://groups.yahoo.com/group/http-wg/message/7021

    (You're right about the quality and specificity ordering, but listing order should not be a factor.)


    The only reason order would be a factor is because the server will typically choose the best match. Quality first, then specificity, then finally, whichever the client requested first.
  • Anonymous (unregistered) in reply to Eric

    I was wondering why that first post is all WTFED up.  The rest are fine for me, it's just that first one that doesn't line wrap properly. 


  • (cs) in reply to Anonymous

    My interpretation of the RFC is that Accept types should be returned in the following order:

    1) Higher q= factor before lower q= factor
    No q= defaults to q=1
    Valid ranges for q are 0 to 1

    2) BETWEEN TYPES WITH THE SAME q= FACTOR:
    Higher specificity before lower specificity
    text/html;index=1
    text/html
    text/
    /*

    3) BETWEEN TYPES WITH THE SAME q= FACTOR AND SPECIFICITY:
    No further ordering is implied by the RFC

    Thus, web servers and user agents are perfectly free, if they wish, to naturally extend the RFC by adding an "order-of-occurrence" tiebreak for entries of the same q= factor and specificity.  Whether this is correct or not is subject to debate.

  • (cs) in reply to Eric
    Anonymous:
    Yeah, can you guys try to do a better job of making these posts Firefox (Gecko, actually) freindly? Many of them require lots of horizontal scrolling which is a big no-no in web design.

    What makes you think the top post is IE friendly? The only thing it is, is megamonitor friendly. Would have been nice if a few more line breaks were added to it.

    Be glad it isn't phpbb, which still defaults to a single table, so EVERY post gets stretched out as much as the widest post. That's the real BS.
  • robbak (unregistered) in reply to makomk

    This really should be brought to the attention of whatever consumer organizations exist in your country. In a market that charges per byte, overlong headers are at best a bug, at worst, dishonest.

    If you have, or live in a market where these phones are in use, then a well-formed letter to your consumer advocates is in order.

  • Random Passerby (unregistered) in reply to Kevin
    Anonymous:
    From page 100:
       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."
    This means "if you cannot give me an audio/basic file, choose whatever format you can give with no more than 80% degradation". Obviously 0% (qvalue of 1) is most desirable.
    No, it means "if you cannot give me an audio/basic file, then give me whatever you have, but I only consider it 20% as good as an audio/basic".  The actual percentage is irrelevant in the case where there's only two options, as it's only used to indicate a preference order.  Note the earlier example where the items are listed out of preference order -- the order in which things are listed is NOT SIGNIFICANT.
    Anonymous:
    Check out this post of notes from an IETF meeting that discusses this very topic in more comprehensible language:

    http://groups.yahoo.com/group/http-wg/message/7021

    That's referring to something entirely different.  Just because both refer to the word "quality" doesn't mean that the word is being used in the same sense in both places :)

  • Dave (unregistered) in reply to David P. Murphy

    I think he's right - it's because they charge by the kilobyte. Ouch - around 1275 bytes just for one mostly worthless header. How much does *that* cost per request?
    I agree with your cynicism; however, I'm not sure why "Accept: */*" is not considered "entirely worthless".

    ok dpm

    Assuming they are still using WSP, that accept header compresses down quite a bit. IIRC, the byte sequence { 0x80,0x00 }, for instance, is equivalent to "Accept: */*".
    Of course, where WSP giveth, WSP taketh away. A single header with multiple values is encoded as header: value1,header: value2, ad nauseam.
  • Kevin (unregistered) in reply to Random Passerby
    Anonymous:
    That's referring to something entirely different.  Just because both refer to the word "quality" doesn't mean that the word is being used in the same sense in both places :)


    What is it discussing then?  Looks to me like content alternatives in HTTP requests for media type, encoding, and language.  Plus the qvalue usage follows the same pattern.

    Also, consider, why else would the qvalue exist?  If the qvalue was *only* for "preference", then why not simply list types in order of preference?  (Which is what the default of no q= does.)  Also, why is it called "quality" instead of something more like what you describe, "preference"?  Seems rather ridiculous to call it "quality" if it means "preference".


    O'Reilly writes a less-technical description of HTTP headers. Let's see... Accept-Language: language qvalue.

    Multiple languages can be listed separated by commas. The optional qvalue represents, on a scale of 0 to 1, an acceptable quality level for nonpreferred languages. Languages are written with their two-letter abbreviations (e.g., en for English, de for German, fr for French, etc.). See Appendix B for a listing of languages.

    "Acceptable quality level for nonpreferred languages"

    It's very easy (as you prove) to muddle the point. The quality is not referring to preference, but QUALITY. However, since the number is usually lowest for nonpreferred types, it is common to describe the qvalue as a preference ranking. (Which is pretty much all anyone really used it for anyway.)

       The example

       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."

    How is this supposed to be interpreted any other way than "send me whatever you can convert it to with no more than 80% degradation"?

    It's easiest to understand the point when you realise converting anything (encoding, language, media type, etc) will always result in some loss of quality. With the qvalue you were supposed to be able to request conversion not take place if it degrades quality too much.
  • primarily_defence (unregistered) in reply to Mung Kee
    Mung Kee:
    // need to set the mime type if it hasn't been set yet, we'll accept all mime types
    // because there should be no bias.


    Congratualtions, you were just now a victim of a drive-by JEDism :P
  • Ralp (unregistered) in reply to Kevin

    Hi,
    content negotiation q-values as sent in a user agent's request headers are used to help the server decide what type of file to serve.  That is, they are just preference rankings; they do not expect the server to do any sort of conversion.  For instance, "Accept: image/png, image/gif; q=0.8" just means we would rather have a png instead of a gif, in case the server has more than one format of the image resource at the requested URI.
    The server can also store its own q values.  For instance, if we have both application/xhtml+xml and text/html versions of a document at a URI, we would probably prefer to serve the former, so let's say we decide mark down the quality of the latter to 0.7.
    Now say a request comes in to our server from a user agent that would rather just have plain text, but can handle html or xhtml, so it sends the header: "Accept: text/plain; application/xhtml+xml; q=0.6, text/html; q=0.8"
    To perform content negotiation, the server just multiplies it's serving preference by the user agent's preference to get the ranking for each mime type.  We don't have a text/plain document at this URI so the server's q value is 0.

    application/xhtml+xml: q = 1 * 0.6 = 0.6
    text/html: q = 0.7 * 0.8 = 0.56
    text/plain: q = 0 * 1 = 0

    So, the server should serve the xhtml document.

  • (cs) in reply to Kevin
    Anonymous:
    Anonymous:
    That's referring to something entirely different.  Just because both refer to the word "quality" doesn't mean that the word is being used in the same sense in both places :)


    What is it discussing then?  Looks to me like content alternatives in HTTP requests for media type, encoding, and language.  Plus the qvalue usage follows the same pattern.

    Also, consider, why else would the qvalue exist?  If the qvalue was *only* for "preference", then why not simply list types in order of preference?  (Which is what the default of no q= does.)  Also, why is it called "quality" instead of something more like what you describe, "preference"?  Seems rather ridiculous to call it "quality" if it means "preference".


    O'Reilly writes a less-technical description of HTTP headers. Let's see... Accept-Language: language qvalue.

    Multiple languages can be listed separated by commas. The optional qvalue represents, on a scale of 0 to 1, an acceptable quality level for nonpreferred languages. Languages are written with their two-letter abbreviations (e.g., en for English, de for German, fr for French, etc.). See Appendix B for a listing of languages.

    "Acceptable quality level for nonpreferred languages"

    It's very easy (as you prove) to muddle the point. The quality is not referring to preference, but QUALITY. However, since the number is usually lowest for nonpreferred types, it is common to describe the qvalue as a preference ranking. (Which is pretty much all anyone really used it for anyway.)

       The example

           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."

    How is this supposed to be interpreted any other way than "send me whatever you can convert it to with no more than 80% degradation"?

    It's easiest to understand the point when you realise converting anything (encoding, language, media type, etc) will always result in some loss of quality. With the qvalue you were supposed to be able to request conversion not take place if it degrades quality too much.

    Wait, wait, what's a lower quality language? I can ask for good german, mediocre japanese, or really muddled engrish? xD

    I think you're really getting mixed up over the term quality. For one, servers don't have any way of assigning quality values to files and formats (it's technically possible, but it doesn't exist); servers definitely won't convert multimedia into anything of any quality, and even if they have various types and a mime mapping set up, they would rely on your list of preferences, going down the list by quality order, and finally just giving you something random (or a 404 if you have no "audio/*"). Hell, servers with mime mappings failovers even set up are few. Servers that actually do this sort of thing, like shoutcast and MS streaming media, have entirely different methods of requesting preferred formats and reduced quality.

    I'd suggest taking some time to peruse IETF's mailing lists, where every reference to qvalue refers only to a list of preferred types in order.

Leave a comment on “Mobile Inflation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article