Re: [whatwg/xhr] Web compat implications of making getAllResponseHeaders lowercase (#146)

I know it's not much help now, but FWIW if anyone had [filed a bug on Chrome](https://crbug.com/wizard) describing some of the breakage here during the couple months while Chrome 60 was in [dev or beta stage](https://www.chromium.org/getting-involved/dev-channel), I personally would have argued for holding off from shipping this change to better understand the web compat trade-off (and, from what I'm hearing here, I suspect we'd have decided to undo the change).  We have a substantial fraction of Chrome users running dev and beta builds and have [generally found we can rely on](https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.br2x161kh4n) the regression bugs filed during beta (or lack thereof) being a strong predictor of the risk.

So if you have applications deployed in a way you can't easily update, then please do at least some of your testing or dogfooding on Chrome dev channel and file bugs when you hit problems (issues of the form "this page at this URL works in Chrome N but not Chrome N+1" do generally get handled quite quickly). Beyond intentional breaking changes like this (which are rare), there are always bugs.  Regression issues in chromium do tend to get [resolved quickly](https://www.slideshare.net/robnyman/predictability-for-the-web/40-Example_intervention_throttled_rendering_Dont).

But in this case we learned of these issues too late to change Chrome 60 and Safari 11, so most of the damage is done and we're stuck with the change.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/issues/146#issuecomment-321411873

Received on Wednesday, 9 August 2017 23:50:16 UTC