Comment On Mobile Inflation

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

So isn't this bit backwards?

application/xhtml+xml, application/vnd.wap.xhtml+xml

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



-- thick sarcasm --

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.

What if * gets redefined?

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.

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

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?

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.

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?

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



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

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.

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?

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

WTF

 

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.

 

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

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.

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.

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.

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.

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

ININITRY PLUS ONE!!!

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.

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.

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

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;

   }

}

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;

   }

}

Okay, I give up.

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.

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 < 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;
   }
}

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.

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.

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

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?

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

YOU FORGOT POLAND!

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.
:)

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

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.

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.

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. 

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.

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.

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.

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 :)

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.

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.

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

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.

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.