W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > July to September 2008

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

From: Luca Passani <passani@eunet.no>
Date: Wed, 06 Aug 2008 22:50:53 +0200
Message-ID: <489A0EAD.1010207@eunet.no>
To: public-bpwg-comments@w3.org

Jo Rabin wrote:
>
> Off the top of my head, I'd say that a requirement has been expressed 
> that users should be able to make that choice. I'm not sure what 
> exactly you mean by "solve", but why don't you submit a proposed 
> change in a formal last call comment?
the problem is that the rule is big enough that transcoder vendors can 
run a train through it. They just need to claim that it's "full web on a 
mobile phone" they are launching, and there you go, everyone gets 
trascoded (this is exactly what VodaUK did, by the way).

What about having a rule that says that Network operators are not 
supposed to make transcoders manage all HTTP requests for their 
main/default WAP configuration on devices?

How do I submit a proposed change?
>
> Also, so far as UA header modification is concerned, I'd observe that 
> there is still the case that the CT proxy may work around 406 and 
> equivalent responses.
as far as I know, this occorunce is not so common, so I don't have any 
particular feeling about it. Am I missing something?

Luca

>
> Jo
>
> On 06/08/2008 16:39, Luca Passani wrote:
>>
>> Jo,
>>
>> What about removing clause 2 of 4.15?
>>
>> specifically the exception that says that headers can be modified if
>> "the user has specifically requested a restructured desktop experience"
>>
>> this would solve the UA issue in one fell swoop
>>
>> Luca
>>
>> Jo Rabin wrote:
>>>
>>> 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
>>
>>
>
>
Received on Wednesday, 6 August 2008 20:51:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:50 UTC