3 ms·

It seems crazy to: 1) Implement a draft header from the W3 at this stage (which I think this is from what I can see.. there's even some fun debate about how m

by Twirrim 11y ago

It seems crazy to: 1) Implement a draft header from the W3 at this stage (which I think this is from what I can see.. there's even some fun debate about how many characters long it should be: https://github.com/w3c/webappsec/issues/216 https://github.com/w3c/webappsec/issues/216). Do they really expect webservers to handle this correctly? 2) Despite having a bug like this open in Beta, allow this to get out to Prod! Surely it's obvious this is a major breaking change?! edit: here's the working draft document: http://www.w3.org/TR/upgrade-insecure-requests/#preference http://www.w3.org/TR/upgrade-insecure-requests/#preference

martius 11y ago
1) Well, web servers are always evolving, think of HTTP/2 :) 2) During the beta, they didn't receive enough feedback to evaluate the criticality of the problem, they assumed that the fix could wait 6 weeks.
tomsommer 11y ago
The header is 9 days old, and now Chrome is sending it by default: https://github.com/w3c/webappsec/commit/eeac3922418bfa6cb254071c74ddd962ee418c80#diff-3545c71e29140b0ee305d62eefac12f4 https://github.com/w3c/webappsec/commit/eeac3922418bfa6cb254... Header bloat, ~28 extra bytes per request from every Chrome user in the world. The whole idea of the header is odd, it should be something the server could send to the client, if needed, not something the client should announce support for. Crazy indeed.
- MichaelGG 11y ago
  Yeah I read the draft and the rationale seems very weak. What's wrong with just sending the Content-Security-Policy header in responses and letting UAs do what they will? Nothing. Same as redirecting to HTTPS if you support it. But for some reason, they had to combine things and want to know if it's "safe" to use HTTPS. They didn't appear to list any real scenarios for this behavior. (Maybe there are, it's not readily apparent though.)

by Twirrim 11y ago

martius 11y ago

1) Well, web servers are always evolving, think of HTTP/2 :) 2) During the beta, they didn't receive enough feedback to evaluate the criticality of the problem, they assumed that the fix could wait 6 weeks.

tomsommer 11y ago

The header is 9 days old, and now Chrome is sending it by default: https://github.com/w3c/webappsec/commit/eeac3922418bfa6cb254071c74ddd962ee418c80#diff-3545c71e29140b0ee305d62eefac12f4 https://github.com/w3c/webappsec/commit/eeac3922418bfa6cb254... Header bloat, ~28 extra bytes per request from every Chrome user in the world. The whole idea of the header is odd, it should be something the server could send to the client, if needed, not something the client should announce support for. Crazy indeed.

MichaelGG 11y ago
Yeah I read the draft and the rationale seems very weak. What's wrong with just sending the Content-Security-Policy header in responses and letting UAs do what they will? Nothing. Same as redirecting to HTTPS if you support it. But for some reason, they had to combine things and want to know if it's "safe" to use HTTPS. They didn't appear to list any real scenarios for this behavior. (Maybe there are, it's not readily apparent though.)