W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

Re: [UPGRADE]: What's left?

From: Ilya Grigorik <igrigorik@google.com>
Date: Wed, 11 Mar 2015 09:20:37 -0700
Message-ID: <CADXXVKoun-QFm15rdaAr_oZDFqavceyW=SrSZE=09nPj9Z1eWA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Brad Hill <hillbrad@gmail.com>, Eric Mill <eric@konklone.com>, Peter Eckersley <pde@eff.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>, Tanvi Vyas <tanvi@mozilla.com>, Yves Lafon <ylafon@w3.org>, T Guild <ted@w3.org>, Daniel Appelquist <appelquist@gmail.com>, Alex Russell <slightlyoff@google.com>, Yoav Weiss <yoav@yoav.ws>, Mark Nottingham <mnot@mnot.net>
On Tue, Mar 10, 2015 at 10:26 PM, Mike West <mkwst@google.com> wrote:

> +1. Albeit treating rel=secure as an implicit redirect still feels a bit
>> odd to me.
> I resolve the oddity for myself by noting that the server _isn't_
> redirecting the client. The _client_, based on the information the server
> provides, is making a decision for itself about what content to display to
> a user. That seems pretty reasonable to me, and in-line with concepts like
> responsive images (where the server says "Here are some options. Pick one
> that makes sense.").

Sure, but the UA automatically makes this decision on users behalf each
time, so effectively it is a conditional server redirect, but with a whole
bunch of gotchas: the server has to render full (200) response in case the
client is not "capable"; the client incurs the cost of downloading said
response (at a minimum some of it, most likely all of it); the perf+timing
specs now have to account for completely new type of redirect; crawlers
need to be updated to account for this signal... all because we're
overloading 200 with redirect semantics, which is really painful. I'd
*much* prefer if we retain the current 3XX flow, which would make all of
this transparent to existing tools and implementations.

Received on Wednesday, 11 March 2015 16:21:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:47 UTC