- From: Francois Daoust <fd@w3.org>
- Date: Tue, 24 Nov 2009 15:28:50 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Tom Hume <tom.hume@futureplatforms.com>, Luca Passani <passani@eunet.no>, public-bpwg-comments@w3.org
For clarification, the guidelines do not build on the assumption that GET is not safe. The mechanism described by Luca is actually recommended by the guidelines: send a GET with original headers, then send a request with modified headers if the first response is a "request unacceptable" response. The note on GET being sometimes misused in practice was to target transcoding vendors, to alert them that they should minimize the number of GET requests they send when possible. I register that the use of normative terms for that section could be a problem and that it can be mis-interpreted. This should be addressed by the group. Thanks, Francois, BPWG staff contact. Julian Reschke wrote: > Hi, > > I may be missing something here, but anyway: *any* design that builds on > the assumption that GET is not safe is in conflict with fundamental > architectural principles of the Web -- see > <http://www.w3.org/TR/webarch/#safe-interaction>. > > Don't go there. And in case you are already there: fix it. I don't think > there's an alternative to that. > > Best regards, Julian > > > Tom Hume wrote: >> Maybe I've misunderstood you. You said "t he fact that there may be >> (easily identifiable) cases where multiple GETs may change the status >> of the site, does not mean that probing the site cannot be performed >> safely for all the parties involved." >> >> Who's taking on the responsibility for easily identifying cases where >> a site receive multiple GETs and ensuring this is a safe operation >> (which doesn't affect site statistics, protection of content, or >> generation of files)? If it's the site owner, then you're expecting >> them to make (simple) changes to accommodate these situations, aren't >> you? >> >> 2009/11/24 Luca Passani <passani@eunet.no <mailto:passani@eunet.no>> >> >> >> You don't want to go around the houses again, but you keep deriving >> implications from my words which are not there. >> >> In the case of probing there is *nothing* that a site owner must do. >> In your case, the site owner must modify the way their site works. >> >> It is up to a proxy to recognize that a URL is pointing to a JAD >> file and probe should not take place. >> >> Luca >> >> Tom Hume wrote: >> >> Not that I'm going to go around the houses with you on this one >> again, Luca... >> >> My point is, you're applying a double standard: in the case of >> probing you're expecting site authors to account for it (which >> as you say, they can do easily). In other cases (looking at >> different HTTP headers or adding a no-transform directive) >> you're saying it's unreasonable for them to be expected to make >> changes. >> >> I think either position could be consistent by itself, but >> together they're contradictory. >> >> 2009/11/24 Luca Passani <passani@eunet.no >> <mailto:passani@eunet.no> <mailto:passani@eunet.no >> <mailto:passani@eunet.no>>> >> >> >> Tom Hume wrote: >> >> I agree, it can be done safely and easily - though many to >> date haven't done so; in much the same way that site >> authors >> can reconstruct original headers by looking at >> X-Device-User-Agent, and prevent transformation by >> adding a >> "no-transform" header - safely and easily. >> >> >> I disagree. The onus of safeguarding mobile content sits >> squarely >> on the shoulder of transcoders and operators who deploy them. >> >> It is not fair (nor reasonable) to force everyone to change >> the >> way their web applications work to avoid falling victim of the >> greed of some. >> >> Luca >> >> >> >> 2009/11/24 Luca Passani <passani@eunet.no >> <mailto:passani@eunet.no> >> <mailto:passani@eunet.no <mailto:passani@eunet.no>> >> <mailto:passani@eunet.no <mailto:passani@eunet.no> >> >> <mailto:passani@eunet.no <mailto:passani@eunet.no>>>> >> >> >> I agree that there may be trouble if one downloads a >> JAD file >> multiple times. >> >> I disagree that there may be trouble if a proxy hits: >> >> http://www.acmilan.com/ >> >> in order to check whether a mobile experience is being >> offered or >> not. The fact that there may be (easily identifiable) >> cases >> where >> multiple GETs may change the status of the site, does >> not mean >> that probing the site cannot be performed safely for >> all the >> parties involved. >> >> Luca >> >> Tom Hume wrote: >> >> I've seen mobile content services where >> repeat-GETs cause >> problems. For instance: >> >> 1. Download services that limit the number of >> downloads >> (GETs) >> to protect content assets; >> >> 2. Download services which trigger the build of an >> asset >> server-side (e.g. JAR file for MIDlet) based on the >> User-Agent >> of the first hit; >> >> 3. Statistical analysis of server logs where >> double-hits can >> affect page views, etc. >> >> All these are IMHO common techniques that I've seen >> more than >> one provider of mobile content use. >> >> 2009/11/24 Luca Passani <passani@eunet.no >> <mailto:passani@eunet.no> >> <mailto:passani@eunet.no <mailto:passani@eunet.no>> >> <mailto:passani@eunet.no <mailto:passani@eunet.no> >> <mailto:passani@eunet.no <mailto:passani@eunet.no>>> >> <mailto:passani@eunet.no <mailto:passani@eunet.no> >> <mailto:passani@eunet.no <mailto:passani@eunet.no>> >> >> <mailto:passani@eunet.no <mailto:passani@eunet.no> >> <mailto:passani@eunet.no <mailto:passani@eunet.no>>>>> >> >> >> >> >> Hi Mark, I am not part of BPWG, but I >> followed the >> work of >> the WG >> very closely and I think I can provide some >> of the >> answers to >> your questions (Disclosure: I am the author >> of the >> Manifesto for >> Responsible Reformatting, >> >> http://wurfl.sourceforge.net/manifesto/ >> >> The Manifesto addressed the same issues CTG >> that is >> addressing >> with overwhelming support from the community, >> operators and >> a few >> key transcoder vendors too) >> >> comments (and answers) in-line >> >> >> Mark Nottingham wrote: >> >> >> * 4.1.5.1 "The theoretical idempotency of >> GET >> requests >> is not >> always respected by servers. In order, as >> far as >> possible, to >> avoid misoperation of such content, proxies >> should avoid >> issuing duplicate requests and specifically >> should not >> issue >> duplicate requests for comparison purposes." >> Existing proxies can and do already retry >> GETs; >> I'm not >> sure >> who you're trying to protect here. >> They are protecting Novarra Inc. ( >> http://www.novarra.com/ >> ). "GET >> idempotency" is an excuse to kill a reasonable >> approach to test >> whether a website has a mobile experience >> ready for >> visitors or >> not. Proxies could make a request with unaltered >> HTTP headers, >> ascertain that there is no mobile experience >> ready >> for that >> device >> and move on to spoof the UA string for that site >> from that >> moment >> on (if there is a mobile experience in place, >> then their >> intervention is not needed and in fact totally >> undesirable). >> >> The problem with this approach (for Novarra) is >> that >> this would >> not allow their proxy to fool the website and >> extort >> full-web >> content also in the presence of a mobile >> experience. >> >> Please also observe that "probing" is what some >> commercial >> proxies >> do (and performance is not an issues, because >> nothing prevents >> that a proxy caches the result of recent >> "probs" for >> a few >> hours). >> >> >> My concern is that Recommending this >> document will >> cause more >> harm than good to the Web overall (even if >> it does >> represent a >> consensus of sort among a more limited >> community). >> >> >> I of course agree. Just wanted to observe how >> the >> "limited >> community" is in fact "very limited", since >> it only >> accounts for >> the needs of some transcoder vendors and >> Vodafone. The >> overwhelming majority of the mobile ecosystem >> hates >> transcoders >> and support for the aforementioned Manifesto >> proves >> this. >> >> Thank you >> >> Luca >> >> >> >> >> >> >> -- Future Platforms: hungry and foolish >> since 2000 >> work: Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com>> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com>>> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com>> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com>>>> play: tomhume.org >> <http://tomhume.org> >> <http://tomhume.org> >> <http://tomhume.org> <http://tomhume.org> >> >> >> >> >> >> >> >> >> -- Future Platforms: hungry and foolish since 2000 >> work: Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com>> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com>>> play: tomhume.org >> <http://tomhume.org> >> <http://tomhume.org> <http://tomhume.org> >> >> >> >> >> >> >> -- Future Platforms: hungry and foolish since 2000 >> work: Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com> >> <mailto:Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com>> play: tomhume.org >> <http://tomhume.org> <http://tomhume.org> >> >> >> >> >> >> >> -- >> Future Platforms: hungry and foolish since 2000 >> work: Tom.Hume@futureplatforms.com >> <mailto:Tom.Hume@futureplatforms.com> play: tomhume.org >> <http://tomhume.org> >> >> > > >
Received on Tuesday, 24 November 2009 14:29:27 UTC