RE: ISSUE-255 (the mdot thing): Subdomain and Path as a heuristic in content transformation [Content Transformation Guidelines]

Actually, they don't ("proxies fielding redirect requests"), except as a
proprietary feature of some WAP1 gateways which works with clients of
the same vendor or that implement the proprietary methods. Since WAP2
requires normal behavior as a HTTP proxy and there are no standard HTTP
features to negotiate use of such a feature, or enable the client
discovery that a proxy-based redirect has occurred, this is not
supported in a standard way by any WAP gateway or HTTP proxy that I am
aware of.

Actually in 2003/2004 I led a work item in OMA to implement a feature
for this, called "Proxy-Based Redirect". We intended it to reduce the
over-the-air (OTA) latency of redirect, since at the time (GPRS days)
redirect was a significant factor for service latency. I worked out some
of the details at that time (e.g. headers, semantics, implications) but
the implications prevented it from being pursued to completion. One of
the major limitations was that it only benefits non-secure HTTP
requests, at least the OTA round-trip saving occurs only for non-secure
requests.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Francois Daoust
Sent: Friday, June 06, 2008 9:53 AM
To: Jo Rabin
Cc: Mobile Web Best Practices Working Group WG
Subject: Re: ISSUE-255 (the mdot thing): Subdomain and Path as a
heuristic in content transformation [Content Transformation Guidelines]


Do they? (I'm really asking out of curiosity, as I thought none would do
that, actually)

Anyway, I agree we should mention that the final response URI should be
used, whatever the mechanism to get from the initial requested URI to
the final response may be.

Francois.


Jo Rabin wrote:
> Sorry I meant to add that fielding redirect requests is something that

> proxies would most usefully handle in the mobile case, and I expect 
> they do ...
> 
> Jo
> 
> On 06/06/2008 17:06, Jo Rabin wrote:
>>
>> You make a good point (hastens to add that this is far from unusual
>> :-)) when you note that the title of the section is
>>
>>  4.1.2 Proxy Decision to Transform
>>
>> and that is not actually what the section is about.
>>
>> My point here is that this section is really about "proxy forwarding 
>> of request" I think the title is a hang over from a earlier versions 
>> in which is was suggested that the proxy might or might not offer 
>> transformation services etc. which is actually what it says in the 
>> text. I think this definitely needs clarification.
>>
>> Either way, the way it is now, the proxy will not decide whether to 
>> transform the response at the time of the request. What it will 
>> decide is whether to alter the headers (based on user preferences, or

>> prior knowledge that the server will reject the request) or not. Are 
>> we now adding that if the request is to m.whatever then this is an 
>> additional case in which the server will alter the headers? That 
>> seems incoherent to me - why would you alter mobile headers to 
>> desktop headers when you are making a request to a site that is
likely to be mobile friendly?
>> That would be counter-productive, surely?
>>
>> Jo
>>
>> On 06/06/2008 16:45, Francois Daoust wrote:
>>>
>>>
>>>
>>> Mobile Web Best Practices Working Group Issue Tracker wrote:
>>>> ISSUE-255 (the mdot thing): Subdomain and Path as a heuristic in 
>>>> content transformation [Content Transformation Guidelines]
>>> [...]
>>>> a couple of questions:
>>>>
>>>> i) on the request side, how does the URI requested constitute a 
>>>> heuristic, if we are saying that the headers should not be 
>>>> transformed a) unless the user requests it and b) unless the 
>>>> request is rejected?
>>>
>>> I'd say the same way as "the HTTP method of the request" which is in

>>> the list as well, does.
>>> It refers to the proxy's intention to offer transformation services,

>>> and not to the proxy's transformation of the request headers.
>>>
>>>
>>>>
>>>> ii) on the response side, I think we may mean the URI of the 
>>>> response (i.e. content-location or the result of resolving 
>>>> redirects, rather then the originally requested URI, and if that is

>>>> what we mean we should say so ....)
>>>>
>>>
>>> You're absolutely right for the Content-Location case, and for any 
>>> redirect that would be initiated by the CT-proxy (when the CT-proxy 
>>> discovers a <link alternate="handheld"> typically).
>>>
>>> But as for regular 302 redirects, isn't the redirection supposed to 
>>> be done on the end-user side? In that case, from the point of view 
>>> of the CT-proxy, there should be no difference between the requested

>>> URI and the URI of the response (provided there's no 
>>> Content-Location header in the response). Best explained with an
example:
>>>  1. user sends a request on A
>>>  2. CT-proxy sees request on A
>>>  3. server responds with a 302 to B
>>>  4. CT-proxy lets redirect response A go by  5. The user agent sends

>>> a request on B  6. CT-proxy sees request on B  7. server response 
>>> with response for B  8. CT-proxy applies CT on B. For the CT-proxy, 
>>> the request associated to B is on B, and not on A.
>>>  9. The user sees response B for his/her request on A and is a happy

>>> user.
>>> Am I missing something?
>>>
>>> Francois.
>>>
>>
>

Received on Friday, 6 June 2008 19:56:55 UTC