Re: [spec-reviews] Strawman spec review for upgrade insecure requests (#54)

> +
> +### CLARIFICATION: Wording in Terminology
> +
> +The wording "depend on the upgrade-insecure-requests mechanism" in Section 2 is
> +unclear. It seems to mean something like, "the same with and without
> +upgrade-insecure-requests" from context, but I'm not sure.
> +
> +### COMMENT: +1 for Issue #184
> +
> +https://github.com/w3c/webappsec/issues/184 seems like a good thing for
> +improving the smoothness of the HTTP to HTTPS transition.
> +
> +### ISSUE: Need Example for Upgrade Insecure Navigations Set
> +
> +It would be nice to have an example of a CSP directive with an upgrade insecure
> +navigations set in the draft.

This isn't something I intended to expose via the directive, but is instead an implementation detail of the nesting behavior. That is, if `example.com` is loaded at top-level, it upgrades navigational requests to `example.com`. If it loads `not-example.com` in an iframe, navigational requests to `example.com` should still be upgraded in _that_ new context.

If, however, `not-example.com` _also_ sends the upgrade header, then navigations to `example.com` and `not-example.com` should be upgraded. To support this use case, each Document needs to track the origins which ought to be upgraded in its context.

We could probably simplify this by making the list global for everything under the top-level browsing context, now that I think about it.

Filed https://github.com/w3c/webappsec/issues/295.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/pull/54/files#r29022733