Update Redirect section with HTTPS->HTTP behavior

[ericlaw1979]

https://mikewest.github.io/sec-metadata/#redirects explains what to do in the face of redirects, but does not clearly state what should happen on HTTP requests that are generated as a result of HTTPS->HTTP redirections.

Elsewhere in the spec, we have

To set the Fetch metadata headers for a request, given request r:
If r’s url is not an potentially trustworthy URL, return.

... but based on https://crbug.com/964053 it is not fully clear to implementers whether this restriction should apply to HTTP requests that are a result of a redirection.

Similarly, in the case of a HTTPS[1]->HTTP[2]->HTTPS[3] redirection chain, should the metadata headers be added to request number 3?

[arturjanc]

I believe the intent of the spec is to never send Sec-Fetch-* headers on HTTP requests, so the restriction should also apply to those HTTP requests which are a result of redirections from HTTPS. But if we decided otherwise for some reason (i.e. to send the headers in this case) I don't think it would cause any problems.

Similarly, in the case of a HTTPS[1]->HTTP[2]->HTTPS[3] redirection chain, should the metadata headers be added to request number 3?

Yes, they definitely need to be added to request number 3. Otherwise an attacker could always launder their requests via an HTTP redirect to strip the metadata, which would prevent the server from enforcing security logic which relies on the information being present.

[annevk]

This can be closed. Fetch integration covers this.

[mikewest]

This can be closed. Fetch integration covers this.

Agreed.