Re: [UPGRADE]: What's left?

Sorry, just catching up on this spec. Expect some pull requests / issues.

I don't think there's any problem layering in redirect semantics on a 200 -- it's not pretty, but as pointed out, we already do this elsewhere.

A new 2xx is an interesting idea, but probably overkill. 

I wouldn't use Link for this, too many nasty corner cases. E.g., what if <http://www.mnot.net/> sends a Link to <https://other.foo.com/bar?baz>?

Just define a new header; they're cheap.



> On 12 Mar 2015, at 2:56 pm, Mike West <mkwst@google.com> wrote:
> 
> On Wed, Mar 11, 2015 at 7:42 PM, Ilya Grigorik <igrigorik@google.com> wrote:
> There is a difference. In the 200+implicit redirect case, presumably the UA wouldn't even render the content of http response, but it's still forced to download it, which means the user is incurring bytes without even being aware of it.
> 
> Correct. There's a performance impact, but I think it's one we could mitigate by examining the headers as they come in, and canceling the request if/when we see a CSP header containing the upgrade trigger. In Chrome, I'd like to start doing this anyway in order to improve the robustness of both `X-Frame-Options` and the `frame-ancestors` directive (both of which we currently process in Blink after obtaining the majority of the response).
>  
> Between all the issues introduced by adding another redirect mechanism and forcing "Prefer" on all outbound http:// requests, I'd actually (reluctantly, but its "less worse" in my books) prefer the latter.. which would then trigger a 3XX and reuse existing concepts without breaking HTTP semantics, tooling, etc.
> 
> I don't understand the issues you're referring to (again, how do the tools deal with `Refresh` today?), but I know you know this space better than I.
>  
> Again, non-unique. Note also that the opt-in mechanism would also require _rendering_ all of this, which is even slower. :)
> 
> Yes, but this seems like a micro-optimization.. Yes you don't get https:// on "first" visit, but your first request is going out on http:// anyway so a MITM can downgrade you anyway, so we're not losing much..
> 
> That's a reasonable point. I agree that there's not much security benefit to upgrade alone, as it can be trivially stripped. One more reason to consider it a stepping stone in a migration path.
>  
> personally, I prefer the opt-in route with https on second visit. 
> 
> The opt-in is strange to me because the next step seems unambiguous; the server says "Hey, do you support upgrades?", in the next request the client responds "Yes, totally!", and the server responds with a redirect. There's no other action the server can take as a result of the opt-in. It seems strange to pretend that we don't know what the server is going to do, and to wait for explicit confirmation of the redirect that's being implicitly offered.
> 
> Also, note that this only addresses the HTTP->HTTPS use-cases. It doesn't help us address downgrading incapable clients from HTTPS to HTTP to avoid mixed content issues. I don't know how to do that cleanly without sending a positive "upgrade-capable" signal of some sort along with requests.
> 
> -mike

--
Mark Nottingham   https://www.mnot.net/

Received on Friday, 13 March 2015 03:55:36 UTC