Re: Web browsers, HTTP and transcoding

Hi Tom,

We did investigate the idea back in May, see for instance:
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0004.html
http://www.w3.org/2008/05/06-bpwg-minutes.html#item02

The list of "data" Content-Types is fairly limited: application/json and 
application/octet-stream were the only candidates we could think of 
IIRC. text/xml in particular may be used to serve XHTML Basic 1.1 and 
cannot be included in the list:
  http://www.w3.org/TR/xhtml-media-types/#summary

An HTTP exchange that uses such a Content-Type typically follows another 
"regular" HTTP exchange (e.g. a request sent through an XmlHTTPRequest 
object follows a request on the page itself). If the CT-proxy already 
transformed the original page, the script is likely to break anyway. 
This is not an excuse to allow transformation of data content, but one 
could imagine that CT-proxies may be able to transform simple scripts in 
the future. In itself, it would be too restrictive to forbid 
transformation in such cases.

Thinking about the future explains why section 4.3.6 Proxy Decision to 
Transform does not mention any normative mechanism, but only heuristics:
http://www.w3.org/TR/ct-guidelines/#sec-proxy-decision-to-transform

... and why we resolved during last week's F2F to move (and complete) 
the list of heuristics to an appendix so that readers do not confuse a 
list of heuristics with an endorsed and exhaustive list of items that 
must be considered by a CT-proxy before deciding to transform:
  http://www.w3.org/2008/10/20-bpwg-minutes.html#item23

Francois.


Tom Hume wrote:
> Has an approach of not transcoding content types explicitly used for 
> data rather than data+presentation (e.g. text/xml) been considered?
> 
> On 17 Oct 2008, at 08:51, Francois Daoust wrote:
> 
>> In the end, Rotan is right, it is just impossible to identify HTTP 
>> messages intended for "web browsing" using a deterministic algorithm. 
>> Some "magic" is involved, and it simply cannot work in 100% of all 
>> cases. Adding a "Cache-Control: no-transform" directive in an XHR call 
>> (fairly simple to do, provided you know you have to do it, that is) is 
>> the only way to go to make sure CT-proxies would leave the message 
>> untouched.
> 
> -- 
> Future Platforms Ltd
> e: Tom.Hume@futureplatforms.com
> t: +44 (0) 1273 819038
> m: +44 (0) 7971 781422
> company: www.futureplatforms.com
> personal: tomhume.org
> 
> 
> 
>

Received on Sunday, 26 October 2008 17:53:57 UTC