- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 24 Nov 2009 15:11:56 +0100
- To: Tom Hume <tom.hume@futureplatforms.com>
- CC: Luca Passani <passani@eunet.no>, public-bpwg-comments@w3.org
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:12:40 UTC