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

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.

Well, I totally agree to rename that section.


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

Indeed, and the intended message was actually quite the contrary: as 
well as referring to user preferences or prior knowledge, the CT-proxy 
could also refer to an examination of the requested URI, and if it is of 
the form m.whatever, whatever.mobi, ... then it should probably decide 
NOT to alter the headers of the request!

But I agree that it's orthogonal to the "allowed" cases where HTTP 
headers may be altered.
(but then the HTTP method of the request is also orthogonal to these 
cases, and precised later on)

Actually, it is rather one of the things the CT-proxy could use to 
conduct its analysis of what we usually refer to as a "200 Bogus 
response", as a clue that it is probably not dealing with a "200 Bogus 
response" but rather with a mobile response.

I'm not a huge fan of the structure of the section 4.1.2, but I confess 
I don't have any real cool proposal to make things clearer at that point.

Francois.



> 
> 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:48:39 UTC