Re: Web browsers, HTTP and transcoding

Bringing this one back... could we be clearer about concerns when  
dealing with, say, SOAP or other RPC requests?

On 17 Oct 2008, at 08:51, Francois Daoust wrote:

>
> 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
>
>

--
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 Monday, 3 November 2008 15:14:39 UTC