- From: Tom Hume <tom.hume@futureplatforms.com>
- Date: Tue, 24 Nov 2009 14:02:17 +0000
- To: Luca Passani <passani@eunet.no>
- Cc: public-bpwg-comments@w3.org
- Message-ID: <a293dbd10911240602h4d69e19bx2a243481e39ed004@mail.gmail.com>
Maybe I've misunderstood you. You said "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." 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> > > 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>> >> >> >> 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>>> >> >> >> 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>>>> >> >> >> >> >> 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>>> 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> >> >> >> > -- Future Platforms: hungry and foolish since 2000 work: Tom.Hume@futureplatforms.com play: tomhume.org
Received on Tuesday, 24 November 2009 14:03:17 UTC