Mobile Web Best Practices Working Group Teleconference

Issuing two requests, idempotency, comparison, etc

<francois> topic

francois: continuing from last week, what are the dangers of a CT proxy issuing 2 requests and comparing the responses?
... obviously unneccessary traffic/congestion should be avoided
... but there could be a case for issuing a 2nd request with altered HTTP headers in the event that the 1st response is somehow not satisfactory

<francois> PROPOSED RESOLUTION 2.1: in §4.1.2, replace "Issue a request with unaltered headers and examine the response (see 4.4 [...])" with "Issue a request with unaltered headers and examine the response to check whether it's a 'request rejected' one"

<Zakim> rob, you wanted to change "request rejected" for "unsatisfactory"

hgerlach: still remind everyone that there are a lot of one-time URLs used on mobile phones

francois: this "tasting" and possible 2nd request is only used when there is no a-priori knowledge of the server

so subsequent requests to the same server are already using the a-priori knowledge

hgerlach: but often discovery is from one server and delivery is from a different server

<Zakim> jo, you wanted to say that the reference to 4.4 should stay as it is about determining whether the response is mobile friendly

hgerlach: in this case there could be issues with the one-time URL on the delivery server that has not been visited before

seanP: the word "rejected" could be problematic, eg if the HTTP response is 200 OK but we still want something different
... eg a smartphone might get a desktop version and we could want to spoof a less-smart mobile to get a more mobile-friendly presentation

francois: does anyone want to propose more comprehensive text?
... in practice, do CT proxies compare responses from 2 requests and then return whichever they prefer?

seanP: currently no, we only make one request, except where the response has alternate links in it which we then follow

hgerlach: problem is when a CT proxy spoofs a desktop browser 1st - I'd prefer use mobile User-Agent 1st

<francois> PROPOSED RESOLUTION: at the end of §4.1.2, complete "Not to break existing content, the proxy SHOULD send only one request" with "In particular, it SHOULD NOT issue duplicate requests for comparison purpose as a generic rule."

jo: where does this go?

francois: replaces editorial note at end of 4.1.2

seanP: what does the 2nd clause add to the 1st?

francois: it's an example for emphasis, not a seperate requirement

jo: prefer to remove "Not to break existing content"

francois: it is an extract from last week's resolution - but it's in the Editor's hands

<hgerlach> i prefer that what we already have in there in the orig document

<jo> PROPOSED RESOLUTION: Note: CT Prxoies SHOULD avoid sending duplicate requests where [possible and specifically SHOULD NOT send duplicate requests for comparison purposes only

<francois> +1

<hgerlach> +1

<SeanP> +1

<jo> PROPOSED RESOLUTION: Note: CT Proxies SHOULD avoid sending duplicate requests where [possible and specifically SHOULD NOT send duplicate requests for comparison purposes only

RESOLUTION: Note: CT Proxies SHOULD avoid sending duplicate requests where possible and specifically SHOULD NOT send duplicate requests for comparison purposes only

<Zakim> rob, you wanted to ask does it have to be 100% clear?

<jo> ACTION: Jo to propose text for the final part of 4.1.2 taking into account resolutions and discussion on this and the previous call [recorded in http://www.w3.org/2008/05/06-bpwg-minutes.html#action01]

<trackbot-ng> Created ACTION-752 - Propose text for the final part of 4.1.2 taking into account resolutions and discussion on this and the previous call [on Jo Rabin - due 2008-05-13].

Content-types and doctypes

<francois> Sean's list of content-types

<francois> Sean's list of doctypes

jo: do we really want to list all this in our document? Especially as Content-Type is such a broken mechanism in practise
... <DOCTYPE>s are useful and the list is relatively short

<hgerlach> +1

<francois> fd's try to rationalize

seanP: agree with Jo, the Content-Type list is really only examples, it's not complete

<jo> PROPOSED RESOLUTION: Mention content type as a contributory heuristic (no specific mentions) and list the DOCTYPEs mentioned by Sean in http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0000.html

<francois> +1

<hgerlach> +1

<SeanP> +1

+1

francois: and no-one wants to be more restrictive?

RESOLUTION: Mention content type as a contributory heuristic (no specific mentions) and list the DOCTYPEs mentioned by Sean in http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0000.html

<francois> Close ACTION-725

<trackbot-ng> ACTION-725 Send a list of content-types for which content transformation applies closed

Link element in HTML requests

<francois> <link rel="alternate" media="handheld" type="[content-type]" href="[uri]" />

<Zakim> jo, you wanted to express confusion as to what this convention means

francois: question is if you are the mobile-friendly page, do you link to yourself to show you are the handheld version?

jo: exactly, it's a useful mechanism to link to more appropriate versions but how can you identify what user-agents THIS version is suitable for?

seanP: can we ask Aaron? Google likes this mechanism

francois: OK, I'll ask Aaron

AOB: About inclusion of a few points of Luca's manifesto

jo: AOB - there are a couple of things in Luca's "manifesto" that could be useful here

francois: I wanted to report on this on the mailing list 1st then take resolutions in a subsequent call

jo: what if I include them in the next edition and then everyone reviews?

<jo> PROPOSED RESOLUTION: Include X-Forwarded-For and use of meta http-equiv in next rev

+1

<SeanP> +1

<francois> +1

<hgerlach> +1

RESOLUTION: Include X-Forwarded-For and use of meta http-equiv in next rev

<hgerlach> bye