W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > October 2008

Re: Web browsers, HTTP and transcoding

From: Francois Daoust <fd@w3.org>
Date: Fri, 17 Oct 2008 09:51:47 +0200
Message-ID: <48F84413.9040403@w3.org>
To: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
CC: Tom Hume <Tom.Hume@futureplatforms.com>, public-bpwg-ct <public-bpwg-ct@w3.org>

Tom, Rotan,

I just wanted to point out that we had sent a Last Call comment on the 
XMLHttpRequest Level 2 spec a few months ago:
  (and replies)

The comment raised the exact same points you mentioned.

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 


Rotan Hanrahan wrote:
> No. The implications don't go both ways. I was pointing out that a 
> mobile application using Ajax that wants to be immune from interference 
> from an intermediary CT will need to use a payload format that is 
> unlikely to be of interest to the CT. A text/plain payload should do the 
> trick, if the app developer is assuming the CT only looks at the MIME 
> type and won't take an interest in text. If you know that CTs won't 
> manipulate an XML payload that doesn't look like a page, then you can 
> use XML MIME types too. If CTs assume all XML MIME types are adaptable, 
> then you're in trouble with that format.
> However, from the CT perspective you have the problem of trying to 
> distinguish between a normal browser request and a request via XHR, 
> where it is likely that the implementer of the Web application didn't 
> take any action to avoid interference from CT proxies.
> In this case, you might try to be more clever and keep track of the MIME 
> type of the previous request (in the same session?) of the the device 
> and look for unusual shifts between markup types. You could sniff the 
> beginning of the page to see if it really is a page, or just a fragment, 
> or some crazy invented XML language. There's no easy answer when you're 
> a CT and trying to deal with XHR apps that didn't anticipate your presence.
> It would certainly be nicer if XHR flagged itself in the UA, but I think 
> we're too late.
> ---Rotan
> ------------------------------------------------------------------------
> *From:* Tom Hume
> *Sent:* Fri 17/10/2008 00:02
> *To:* Rotan Hanrahan
> *Cc:* public-bpwg-ct
> *Subject:* Re: Web browsers, HTTP and transcoding
> Does this imply that transcoding proxies shouldn't transcode items of 
> content with MIME types that is "text/xml, application/xml or ends in 
> +xml (ignoring any parameters)" (the ones referred to in the XHR standard)?
> On 16 Oct 2008, at 23:51, Rotan Hanrahan wrote:
>> In these scenarios, mobile Ajax should stick to raw text, XML or JSON 
>> as a payload format. If it is communicating with fragments of HTML and 
>> you've already adapted (or otherwise "enhanced") the page in which the 
>> Ajax is operating, the chances of that fragment of HTML being of any 
>> use any more (adapted or not) are significantly diminished already.
>> Good point about the UA though. I must double-check.
> --
> Future Platforms Ltd
> e: Tom.Hume@futureplatforms.com <mailto:Tom.Hume@futureplatforms.com>
> t: +44 (0) 1273 819038
> m: +44 (0) 7971 781422
> company: http://www.futureplatforms.com/
> personal: tomhume.org
Received on Friday, 17 October 2008 07:52:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:30 UTC