- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 12 Jul 2016 23:40:03 +0200
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hi Adrien, On Tue, Jul 12, 2016 at 03:24:05PM +0000, Adrien de Croy wrote: > > In this case, it's a fairly popular site in Norway (mytribe.no) running > through a relatively recent nginx (1.8.1 Jan 2016). > > I would have expected that the static css file would come from the reverse > proxy cache and so should have had C-L validated/fixed, maybe it didn't and > the bad C-L is coming from the back end. If it was bad in the backend, normally the front reverse proxies would not forward the extra data. So i guess instead that the frontend is broken. Also you're probably seeing nginx only because it's the one advertising its name but you don't necessarily see what blackbox runs in front of it. If it's an ad injector or whatever similar device, you can reasonably expect it to be broken by default :-/ > But in any case, this isn't really an example of an old or legacy site. > > I guess it's always a problem when any single browser makes a stand. What > we need is for all the browsers to do the same thing. Then the users can't > say "but it works in xxx browser", and site operators have no choice but to > fix it. You forget that people first consider that their browser got broken by an upgrade and revert to the old version. And I'm the first one to do this, I have a terrible experience of constantly changing interfaces forcing me to stay as long as possible on a given version. Similarly if users see that their browser reports broken objects on their favorite web site after an upgrade, they'll simply revert to the previously working version. And that can be much worse because they suddenly stop to apply any security fixes for as long as they can... Willy
Received on Tuesday, 12 July 2016 21:40:39 UTC