Re: Web browsers, HTTP and transcoding

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:
  http://lists.w3.org/Archives/Public/public-webapi/2008May/0064.html
  (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 
untouched.

Francois.


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