Content Transformation Addendum to Web Browsing Style Guide
If you have taken the time and trouble to create a "made for mobile" experience, the last thing you would want is that this gets altered by a third party.
We've published a consultative document that suggests ways for you to stop that happening. We suggest that by adding two existing HTTP headers to responses, content providers can make it absolutely clear what they expect content transforming proxies to do with their content. By adding these headers, transforming proxies should be in no doubt what the content provider has in mind.
We know this means extra work for developers, and that's a pain. But a small one. We think that this is a lot less work than trying to get yourself white listed by everyone concerned.
In short, we say that if you put "no-transform" in a Cache-Control header then that makes it clear to transforming proxies that they must not touch your content.
We also say to put a "Vary" header on your response. If you say "Vary: User-Agent" that makes it clear to a transforming proxy that if they have replaced the user's actual User Agent string, then the content they've received is probably not the right content.
Andrea has written an article about how to configure your server environment, or edit your php or asp scripts to do this.
We appreciate that this is a small part of the solution to a really complex issue. We know a lot of developers feel passionate about dealing with these issues - and for those content providers that have been economically affected, understandably.
We are anxious to help develop a more complete solution that addresses a whole range of issues and hopefully restore some balance to the fragile, but growing mobile ecosystem.
To that end we strongly support and are highly active in the W3C Mobile Web Best Practices Working Group, and its Content Transformation Task Force. The group plans to publish guidelines in draft form in October and for full public comment in mid-December. In the meantime the group works in public, and the Editor's drafts of the documents plus the discussion on the list are available to anyone who cares to take an interest.
Please bear in mind that the group hasn't made up its mind about any particular solution, and that contributions of the participant's opinions are made in good faith and in the spirit of exploring the options. It may be that we are strongly opposed to each other's views as initially expressed.
That said, however strongly we disagree, we have committed to finding consensus. It's not always easy to do, but it does recognise that no single point of view or special interest should prevail over others. This is an eco-system that has to work as such. We think that working in that forum is the way to achieve it.
In the meantime, please consider our recommendation that you make absolutely clear what your intentions are in respect of your content.
Jo
Posted by Jo Rabin 4 years 34 weeks ago
CTO at dotMobi, co-Chair of the W3C Mobile Web Best Practices Working Group, co-Organiser of MobileMonday London.
Posted by passani 4 years ago
Hi, I think operators should not be allowed to place reformatting proxies between surfers of the mobile internet and mobile internet content. At least, not without a user explicit opt-in.
Unfortunately, some operators are doing exactly that. Until the day someone will take them to court about their anti-competitive behavior, developers will need to find ways to hack around the problem.
In this context, the no-transform directive is probably a good idea. It helps with vodafone and does not hurt with existing operators (at least, to the best of my knowledge).
I wouldn't necessarily agree about the "vary" header though. VodafoneUk, for example, has demonstrated that they intend to squeeze third-party content developers out of their network. Their excuse is that your "reformatted web site" is better for their users than your "mobile-optimised site", no matter what you, as a developer, think about it.
Being this the environment for developers, adding a "vary:user-agent" header (as suggested by your article) may be exactly what hostile operators like vodaUK need to recognize your service as one that needs to be "messed with". In short, I wouldn't rush to add the vary header...
Luca
Posted by michele 4 years ago
My tuppence worth is that the proposed solution helps, but I'm afraid doesn't cover all cases.
It is assumed that the transforming proxy will honour HTTP standard by properly supporting all headers we may put in the server reply. I'm well aware that this assumption is unavoidable within the context of this discussion. Nevertheless, the recent move of Vodafone UK, that mangles several headers even in the HTTP request, in my opinion showed very clearly that the assumption may prove wrong (server does not get what it should).
Moreover, in the same Vodafone UK case the proposed solution could not be enough even if properly supported by the transforming proxy. Upon receiving the "Vary" header in the reply, the transforming proxy understands that what it got is not the right content as it's aware of playing tricks with the User-Agent. So how does it proceed? I see three possible path for it to follow:
First and second cases yield a bad result. What about the last one? Apparently it solved the problem.
But what if the URL is a dynamic one, unique for that customer, and with restrictions like "you cannot download it more than N times (with N little)" or "you cannot download it again with a mobile terminal different from the one used first time (because it's likely not you, but a friend of yours)"? Keeping superdistribution under control is an important issue when delivering contents.
My point boils down to this: mangling the first HTTP request may be enough to have some damage done. To avoid that, we need to include in our server lines of code that check for the pattern specific to that carrier and handle it as a special case. It's not a nice perspective to think that every carrier out there may want to become yet-another-special-case.
Michele
Posted by Jo Rabin 4 years ago
Hi Michele
"but I'm afraid doesn't cover all cases."
No, it doesn't; in fact it's just a start.
"But what if the URL is a dynamic one, unique for that customer .."
Yes, good point which needs to be factored into the solution. Remember this is not a guideline as to how the trancoding proxy is supposed to work, it's a guideline for servers. W3C Content Transformation Task Force is working on the guidelines for proxies.
"My point boils down to this: mangling the first HTTP request may be enough to have some damage done. To avoid that, we need to include in our server lines of code that check for the pattern specific to that carrier and handle it as a special case. It's not a nice perspective to think that every carrier out there may want to become yet-another-special-case."
The point of the work that is going on is to try to avoid that. Per operator code would be an unacceptable outcome in my view.
Jo
Posted by atrasatti 4 years ago
Quoted text from Michele's post:
"My point boils down to this: mangling the first HTTP request may be enough to have some damage done.
To avoid that, we need to include in our server lines of code that check for the pattern specific to that carrier and handle it as a special case.
It's not a nice perspective to think that every carrier out there may want to become yet-another-special-case."
Do you think that if the proxy used a HEAD request as per HTTP spec would help? I don't know what happens in your code and in everyone's code today, but the HEAD request is used by the client to get "metainformation contained in the HTTP headers". In this case your application would not be serving the content, in facts and should not count this request as a real content download.
I know that a HEAD request would increase the load on your servers and that is not welcome, but it would also overcome a big problem. Transcoding proxies might (and probably should) remember that your server is able to provide mobile-friendly content and stop transcoding. The HEAD request could be issued once, or once every X days, or once per user ever.
See also:
Andrea Trasatti
Director of Device Initiatives, mTLD
Blog: Andrea Trasatti's tech notes and more
Posted by michele 4 years ago
HEAD would help to keep the hit counter "right", but doesn't change the need to have the content "collapse" from a range of possible formats to a very specific one. The server must reply with all proper headers, including content/type and length just to name a few.
Posted by normat1211 17 weeks ago
If you want to add specific HTTP headers to your pages and applications there are many different solutions depending on your environment. There are a lot of reasons why you would want to add an HTTP header, but in this article I want to use as an example a couple of headers that will help you declare that your content should not be transformed and, if you do content adaptation, which headers you use to detect the browser and the device.
normativa construccion
*What do you do when the only person who can make you stop crying is the person who made you cry*
Posted by xiaopy12 1 week ago
Christian Louboutin Sale ghrtu