Re: Web browsers, HTTP and transcoding

Hi Tom,

Here I am with my usual links ;-)

We received a comment on section 4.1.3 that says that a CT-proxy must 
stay transparent if it's not able to determine positively that the 
message is for "Web browsing". The comment ended by "In any case, 
putting a MUST-level requirement on this seems strange":
 
http://lists.w3.org/Archives/Public/public-bpwg-comments/2008JulSep/0136.html
  (part on section 4.1.3)
  (LC-2069 in the Last Call Comments tracker)

We agreed with that comment. Such a normative statement cannot be 
enforced. So we basically decided to switch this to informative (hence 
the use of "ought to" in the resolution below)

RESOLUTION: ref LC-2069. Resolved yes, with the replacement text: Before 
altering aspects of an HTTP request proxies ought to take account of the 
fact that HTTP is used as a transport mechanism for many other 
applications than "Traditional Browsing" and that alteration of HTTP 
requests for those applications can cause serious misoperation.

See: http://www.w3.org/2008/10/20-bpwg-minutes.html#item03

Jo has ACTION-865 to "word smith resolution on LC-2069 in line with its 
spirit and come up with something a bit cleaner and more comprehensible".
If you want to provide some text, feel free to do so :-)

Francois.


Tom Hume wrote:
> 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:47:59 UTC