- From: Tom Hume <tom.hume@futureplatforms.com>
- Date: Tue, 24 Nov 2009 13:45:31 +0000
- To: Luca Passani <passani@eunet.no>
- Cc: public-bpwg-comments@w3.org
- Message-ID: <a293dbd10911240545t39d5343frc5f723305e727cf1@mail.gmail.com>
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. 2009/11/24 Luca Passani <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>> >> >> >> >> 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> >> 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 13:46:25 UTC