Re: what constitutes an "invalid" content-length

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 ( 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...


Received on Tuesday, 12 July 2016 21:40:39 UTC