Are You MobileOk?
Author(s) and publish date
- By:
-
-
Marie-Claire Forgue
-
- Published:
Another one to go. The biggest mobile industry event is taking place in less than a month. Huge really -- maybe too big, for my own taste. I miss the time when it was held in Cannes: it was easier to meet people, quicker to walk through the entire show, nicer to recharge one's batteries in the sun while listening to the sea waves.
Years before launching the W3C Mobile Web Initiative in May 05, we were already listening to the mobile industry heartbeats, watching and prompting for any sign of interest in the mobile Web. We were convinced that the users would want their Web on the move, but it wasn't clear how long we would have to wait for adoption. While waiting, we saw SVG Mobile become a mandatory implemented feature in smart phones, and we applauded XHTML Basic embraced by early mobile browsers.
The time has come now, as many refer 2008 as "the year of the mobile Web". And W3C will be at the congress to tell that Web standards are key to make the mobile Web a success story. Our booth will be located in Hall 7 (#7D56), so please come by to say hi. Dom, Matt, François, Stéphane and I will be there to answer any questions you may have, and/or to give you an update of our current activities: W3C mobileOK, best practices phase 2, device descriptions and APIs, WICD mobile, mobile Web in developing countries, mobileAjax, widgets, and more...
Also, we will run a simple fun contest at the booth: if your Web site is mobile-friendly according to the W3C mobileOK checker, then you win what we think will be the coolest T-shirt at the show! No worries, a copy of our handy mobile Web best practices flipcards, plus other MWI goodies, will be offered to the unlucky ones.
Finally, if you have a stand in the congress, let us know if you have a cool demo/application to show. We'll be happy to come talk to you about your work and the Mobile Web Initiative. We believe that W3C Web standards will play an important role in your communications, and we would like to hear what is most important to you.
See you in Barcelona!
To illustrate the quality of the MobileOK test: for image or CSS files, they send a request containing the following Accept header: “application/xhtml+xml,text/html;q=0.1,application/vnd.wap.xhtml+xml;q=0.1,text/css,image/jpeg,image/gif”. Let’s break content negotiation with a test, folks!
That’s all :).
@ Laurens Holst : So long as text/css is on q=1 (which per the HTTP spec is the default for the quality factor) this Accept: header seems quite acceptable.
What would you suggest instead? Note that the MobileOK checker is Open Source and has a Public mailing-list so if it's doing something wrong, you can help.
Olivier: For image requests it should send something like "Accept: image/, */;q=0.5", for CSS requests it should send "Accept: text/css". Anything else is not correct, because e.g. for a CSS file request application/xhtml+xml is NOT an acceptable response.
The problem here is that the current header tells the server that it is an acceptable response and is thus lying to the server, breaking content negotiation in the process because the server can’t rely on the header. It is better to not send an Accept header at all, then, rather than sending a bogus one.
I sent this as a remark to the list but it was not acted upon because it would be ‘too large a change’ and they didn’t want to risk having to do another Last Call, or something like that. Whatever, but the test has lost its credibility for me now.
~Grauw
@Laurens - your understanding of an Accept: header is not the same as mine. What you just wrote implies that the User-Agent knows what it is requesting before receiving the response, that is, before knowing the content-type.
A user agent is seldom acting as "I am requesting an image now so I will only accept image media types". Rather, the UA is set to fetch a resource, dereferences a URI, and tells the server what it can generally accept.
I'm curious where in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 you see that a User Agent MUST know in advance what type of resource it's going to request and MUST limit its accept headers to it. I don't see that, and neither do I think it would make sense.
The Accept: header sent by this checker may not be to your liking, but as far as I can tell it's not at all bogus according to HTTP.
Olivier: I’m talking here about the requests resulting from <img> and <link rel="stylesheet"> elements, and <?xml-stylesheet?> processing instructions. In those cases the browser knows in advance which type it supports and expects.
Just look at the first line of that section you reference: "The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types". Doesn’t that explain the workings of the Accept header sufficiently? Do note that this information is local to that single request, and does not mean ‘a list of all the types that the browser might request at some point’ (as the use in the mobileOK spec suggests).
Don’t be confused by the ‘can’ either, it means that the Accept header is optional, not that you can put arbitrary stuff in the Accept header (otherwise it would have been capitalised). If the Accept header could have arbitrary contents, it would be utterly pointless and there would be no need to send it in the first place because the server can not reliably use it to make an informed decision on what content to send to the client. Which is what we call ‘content negotiation’, and which is exactly why it’s bad to send false Accept headers, because it induces servers to send content which the client cannot understand, even when they might have a representation which the client does understand.
In pretty much all cases the User Agent is aware of what types of content it can process. A web browser knows that it can process and show text/html, image/gif and text/plain to the user, and an <img> tag knows that it can show image/gif. That information is used to construct the Accept header. If the user agent does not know of this in advance, it should simply not send an Accept header with the request.