- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 17 Jul 2012 14:08:17 -0700
- To: Karl Dubost <karld@opera.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CABP7Rbe_s==22ESQZXkFgzezOTg5ORwtiJzSa9npPOUfZKd5aw@mail.gmail.com>
+1... I was getting ready to respond to Julian's post with a "+1 YEAH!" but then stopped and thought about it... using a URI, while potentially sound in theory, would likely just end up with a different form of the same mess we're in now. Reducing the User-Agent field to nothing more than a single token with a version identifier seems to me to be the Least Bad Option. - James On Tue, Jul 17, 2012 at 2:01 PM, Karl Dubost <karld@opera.com> wrote: > > Le 17 juil. 2012 à 16:40, Julian Reschke a écrit : > > OMG; that sounds so sane that the only thing I can complain about is the > "x-" prefixed header field :-) > > :) wait a minute > > GET / HTTP/1.1 > Host: www.example.org > Capabilities: <http://example.com/acmeCom/new/shiny/browser/23> > > What is happening when example.org meets the client > > 1. for the first time, example.org might download the URI which might be > huge. It means big latency for replying to the client with the right > content. > > 2. to avoid that example.org will be clever, they will cache the > capabilities file and do negotiation on the URI becoming an ID. > > 3. Some business will start by selling list of URIs and capabilities files > (the thing which is happening), create Databases. > > > * Some business will be abandoned. Databases will not be updated. Future > fail > * The cache system will not be maintained. future fail. > * Some scripts will use the URL-ID (new useragent string) to block, > filter, redirect. > > Basically exactly back to the same situation we have today. > > > -- > Karl Dubost - http://dev.opera.com/ > Developer Relations, Opera Software > > >
Received on Tuesday, 17 July 2012 21:09:15 UTC