[upgrade-insecure-requests]

> feedback due by: 2015-11-08

Sorry for my late feedback on [1]

> or host is a congruent matchfor [sp; missing space after markup] a Known HSTS Host which asserts the preload directive.

> A similar effect could be achieved by making this redirect response uncachable [sp] via the Cache-Control header:

Please use `uncacheable`

> Megacorp, Inc. wishes to migrate http://example.com/ to https://example.com.

Why does the first url end in a `/`, but not the second?

> In Nginx, adding this header might look like this (note the use of the preloaded [sic] directive,

* I think you mean `preload`.
* Please link something in this text to wherever that is defined...

> which signifies that this origin’s HSTS state can be safely imported into user agents' HSTS preload lists):

>  add_header Strict-Transport-Security "max-age=10886400; preload"

> Let tuple be a tuple of the protected resource’s URL's host and port.

You're mixing fancy and plain apostrophes here (my copy+paste may have
simplified).

Generally you seem to use fancy.

> Authors can determine whether or not upgraded resources' original URLs were insecure via Content-Security-Policy-Report-Only.

Here again, you used a plain apostrophe

> If a Document's incumbent settings object’s insecure requests policy is set to Upgrade,

And here, the first apostrophe (but not the second) is plain

> It’s important to note that the rewrite happens before either Mixed Content [MIX] or Content Security Policy checks take effect [CSP].

either => both
or => and ??

> Note: Though the Upgrade-Insecure-Requests header expresses a preference, sending it via the existing Prefer header is problematic, as we expect the response from the server to use it as part of the cache key. Vary: Prefer is too broad, as discussed in w3/webappsec#216.

cache key => cache key (Vary)

Note that `use it` is really awkward, I'd suggest `designate it` or
`reference it`.
Also, `cache key` is probably wrong, the server isn't creating or
using a cache key, it's making suggestions about _attributes_ for
caching.

> The Augmented Backus-Naur Form (ABNF) notation used in §3.1 The upgrade-insecure-requests Content Security Policy directive is specified in RFC5234. [ABNF]

Please put the `.` after the `[...]` as in:

> When a server encounters this preference in an HTTPS request’s headers, it SHOULD include a Strict-Transport-Security header in the response if the request’s host is HSTS-safe or conditionally HSTS-safe [RFC6797].

> Set settings' insecure requests policy to Upgrade.

This should be `settings's` or, `settings object's`

note:

> For each value in context’s upgrade insecure navigations set, add value to settings’s upgrade insecure navigations set.

and:

> Set settings object’s insecure requests policy to Upgrade.

(which is admittedly in a different document, but it's probably that
way because I asked for that document too)

> Note: This will be significantly clarified once [CSP] is rewritten in terms of [FETCH].

What does `significantly clarified` mean?
"rewritten", "simplified", "enhanced by examples"

> Note: This algorithm is called as step #3 of the Main Fetch algorithm.

does `called as` mean "replaces", "precedes", "follows", or something else?

> Performing upgrades for navigations to third-party resources brings a significantly higher potential for breakage, so we’re avoiding it for the moment.

I'd love `for the moment` to be clarified -- this was a point I made
@TPAC -- could someone document (a pointer to a non REC track document
would be great) the exit criteria for this note -- i.e. under what
conditions browser vendors would like to change this.

> 5. If request’s url’s scheme is http, set request’s url’s scheme to https, and return.

While websockets don't use fetch, as a reader, it'd be helpful for
there to be an aside: "(WebSockets don't use the fetch algorithm, see
[section on websockets].)"

> 6. If request’s urls port is 80, set request’s urls port to 443.

this should be `request's url's` in both cases (c.f. 5)

> Given an [sic. s.b. "a"] request’s client client

> this algorithm returns Enforced Upgrade if a priori insecure requests associated with that client should be upgraded, or 'Do Not Upgrade' otherwise.

`Enforced Upgrade` is neither quoted nor linkified (but it is teletype).
`'Do Not Upgrade'` is both (although it isn't teletype).

I believe these are the two possible return values, this makes no sense.

> Note: This catches Documents or Workers whose policy

or = > and

> Note: This catches requests triggered from detached clients. Not sure this is necessary, really, given the inheritance structure defined in §3.3 Policy Inheritance.

`Not sure ..` is odd to have in a REC document. I know this is non-normative.
"We are not sure" would be slightly less /awk/ward, but still...

A reference to an issue would be helpful at least.

> Return 'Do Not Upgrade'.

See earlier comment.

> (as discussed at length on public-webappsec@, and w3c/webappsec#216).

Please use a complete email address, you're already inviting spam at
the top of the document, there's no reason to make a reader's life
harder here.






[1] http://www.w3.org/TR/2015/CR-upgrade-insecure-requests-20151008/

Received on Monday, 16 November 2015 19:26:13 UTC