Negotiated options can work IFF the options are always available and work
reliably.
Proxies as have been deployed for http have made many things that otherwise
should theoretically work not reliably work. An example is gzip
compression. Another example was the amazing amount of problems when
attempting to use a different compression algorithm (even when both client
and server spoke it).
Proxy writers can (and often do) have different motivations from the client
and content-provider.
When this happens, optional features/negotiated features are harmful to the
clients and content providers since clients and content-providers are
effectively held hostage by the proxy provider who has all the power.
I am unabashedly against hostage taking. :)
-=R
On Jun 22, 2012 6:37 PM, "Mark Nottingham" <mnot@mnot.net> wrote:
>
> On 23/06/2012, at 10:42 AM, Mike Belshe wrote:
>
> >
> >
> > On Fri, Jun 22, 2012 at 5:10 PM, Roy T. Fielding <fielding@gbiv.com>
> wrote:
> > HTTP predates gzip and cookies. The notion that such a choice had
> anything to do with optional features is just silly. It is optional because
> it barely even worked in practice until 1999 and certainly wasn't feasible
> as a default until a few years after that as CPU capability increased.
> >
> > I'm sorry if this offends - it wasn't intended as a dig against HTTP.
> >
> > The point is that the #1 performance impact in this test was
> compression, which optional in HTTP, and that optional features are not
> used as widely as they could be.
>
> It's actually very widely deployed among browsers.
>
> The issue isn't that it's optional, the issue is that because it's
> negotiated, some intermediaries disable the negotiation to make application
> of policy easier.
>
> We can have a discussion about whether or not we want to prioritise
> performance over these use cases, but let's not kid ourselves that it's as
> simple as "optional = bad." Sometimes there are good reasons to make
> something optional.
>
> Cheers,
>
> --
> Mark Nottingham http://www.mnot.net/
>
>
>
>
>