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

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 16:10:09 UTC