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

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 15:40:00 UTC