Changing User Agent Header Value (was Re: transcoders bad)

This seems to be going round in circles and I am unsure of what points 
are being made. It's going to be difficult for the WG to extract 
specific points to be addressed.

I think that there is a possibility that the discussion is based on 
premises that I don't perceive in the document.

It would be helpful to me, as editor, to know as separate issues:
a) in which ways the document does not make any of it clear,
b) which aspects of what it specifies are objectionable, and what 
possible alternatives there are, given the objectives.

Here's how I see it.

1) Changing User Agent or other headers is not prohibited by HTTP - 
except for as noted under 13.5.2

http://tools.ietf.org/html/rfc2616#section-13.5.2

2) The CT Guidelines don't view the combination of transforming proxy 
and user agent as an extended user agent. That means that the normal 
operation of a CT proxy, as defined by us, is the same as the operation 
of a regular proxy.

3) We specify, over and above what HTTP specifies, that the User Agent 
and other headers should be left alone except in certain specific cases.

4) The first case is where a request, with the original headers, is 
rejected with a 406 error or equivalent. In this case the proxy MAY 
change the headers, but if it does MUST preserve the old ones in a 
different form. The reason for this is that in this case it is likely 
that the site does not have a specific mobile experience, and it serves 
the user's interest to get them an experience of some kind.

The document provides scope for CT Proxies to "remember" previous 
behaviour of Web sites and to short cut content tasting with original 
headers on the basis of that. This seems sensible on the basis that it 
improves user experience and reduces load on servers. However, if CT 
proxies adopt this behaviour then they must be prepared to reverse out 
of it if circumstances change.

Also, there is the possibility that the site really doesn't want the 
user of a mobile device to experience their content, and the option is 
open to them to signal that by using no-transform on the 406 response. 
This seems reasonable to me, given the relative infrequency of this use 
case, and given that special effort has to be taken to reject specific 
user agents in the first place.

5) The second case is where the user has specifically requested a 
restructured desktop experience. This is equivalent in my mind to using 
the Firefox User Agent Switcher.

My personal view is that most users will want to perceive a specially 
crafted mobile experience rather than a restructured experience, but 
other people do not share my view and it is at least conceivable that 
this is the case.

The document says "specifically requested". That means, in my view, that 
it is not established as a default setting.

[In detail there are also cases where a proxy MAY continue with headers 
from a previous request for the sake of continuing an ongoing session 
with some kind of consistency. We're talking about the "initial request" 
here.]

6) Notwithstanding either of the above:

The document says:

... It is anticipated that proxies will maintain preferences on a user 
by user and Web site by Web site basis, and will change their behaviour 
in the light of changing circumstances as discussed under 4.3.4 Receipt 
of Vary HTTP Header.

Section 4.3.4 says that the Proxy must keep an eye out for changed 
behaviour at the server and must re-evaluate both user preferences and 
the allowed short-cut on content tasting if circumstances change.

7) Allow and Disallow lists and what not.

We don't refer to lists in the document on the basis that we model the 
behaviour of the proxy in a black box way, i.e. the details of its 
internal operation are not subject to our specification. However, no 
matter how it works internally, the proxy must change its behaviour in 
the above circumstances.

In my mind this is specifically intended as a work around to real world 
operational problems and to provide a "self-healing" capability for 
incorrectly configured proxies.

8) Summary

The normal course of operation of a conforming CT proxy is not to change 
any header that it is not required to by HTTP.

There are two exceptions where the actual device headers are not 
presented first. They are 1) that the CT proxy is trying to optimise the 
fact that the request with the original headers will be rejected, and 2) 
where the user has specifically requested a restructured version of the 
desktop experience.

In both cases a server will have the knowledge that this is happening 
and may reject this behaviour.

Servers are not required to change their operation. If they decide to 
conform that is their option. If they don't, then conforming CT proxies 
are required in any case to assess whether the server is offering a 
mobile friendly service.


I hope this clarifies any misunderstanding as to what the document says. 
These are my views and not the official view of the Task Force, the 
Working Group, the W3C or any divine being.

Jo



On 05/08/2008 22:45, Luca Passani wrote:
> 
> Sean Owen wrote:
>>
>> It seems pretty simple. If you don't want transcoding, and aren't
>> doing content negotiation, and are already using the HTTP
>> mechanisms properly (i.e. no-transform), then you are done! no change.
>> This recommendation is not proposing anything new.
>>   
> not so. The transcoder may be changing the User-Agent string and still 
> claim that it is conforming to CTGs. How? very simple. The operator just 
> need to claim that it is a "full web on your mobile phone" they are 
> launching (exactly what VodaofoneUK and NOvarra did) and there you go: 
> you get a spoofed UA.
>> If you are doing content negotiation, you need to look for the
>> presence of one new header in the case that you are talking to a
>> transcoder, to both ensure you send no-transform and render for the
>> target device. This seems like two lines of code -- if you're not
>> already looking for this semi-standard header.
>>   
> Terren is right. If we change today, what will prevent Novarra or 
> someone else from asking to change tomorrow?
>> You are angry because you have interests and your interests have
>> clashed with those of transcoders. I am sure that is valid. This
>> document does not only represent content developer interests, but the
>> interests of end users. I don't think it's appropriate for a W3C
>> recommendation to represent only one party's interests, do you?
>>   
> this is a blatant lie. NOvarra, Google, Vodafone and ATT are here for 
> the money. Do not bring users into a discussion where they do not belong.
> Anyway, as I stasted quite a few times, developers are relying on a 
> neutral network for their business. Any attempt to remove neutrality is 
> an attempt to bring the internet back to stone age.
>> Transcoders exist, and they do add value in large number of cases.
> really? I only know of one case: Google.
>>  We
>> wouldn't operate one unless it was quite popular, since people
>> wouldn't use our service, we wouldn't make money.
>>
>> You have a business problem. Luca's solution is "wish that transcoders
>> didn't exist." How's that working for you?
>>   
> well, this is not exactly what I said (I did say that I start to suspect 
> that the only good transcoder I saw was a dead transcoder, but that I 
> was sort of joking). I am OK with transcoders that respect mobile sites 
> without requiring that mobile sites do anything special to protect 
> themselves against transcoders.
>> You are telling me you have a big business problem and won't write two
>> lines of code to fix it? Well, it's up to you I guess. I think this
>> document is aimed at people who want to find practical ways to
>> actually solve the problem.
>>   
> I think the problem is that arrogance cannot be allowed to win.
> 
> Luca
> 
>>
>>   
> 
>

Received on Wednesday, 6 August 2008 09:08:13 UTC