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

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?

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.

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 16:00:31 UTC