Re: Cache control in trailers?

(This thread has gotten extremely long. I've only read the last few
messages.)

On browser handling of truncation, I believe Chrome already enforces
truncation checks in HTTP/1.1. If we don't get the full Content-Length
bytes or if the final zero-length chunk is missing, the network stack will
report an error. The one hack we need is some buggy servers will send the
unencoded length rather than the encoded one. So if we see a truncation but
Content-Length exactly matches the decoded length, we'll clear the error
before reporting it to the caller. (But I believe that happens above all
the connection reuse logic, so protocol-level framing still cares.)

What the calling code does with the error depends on the codepath. Scripts
and CSS only execute atomically (security requirement). HTML is rendered
streaming and, as far as I know, doesn't really care whether there was an
error at the end. Not sure about images. Downloads show an error in the UI.

On Wed, Feb 10, 2021 at 4:35 AM Willy Tarreau <w@1wt.eu> wrote:

> On Wed, Feb 10, 2021 at 10:24:06AM +0100, Daniel Stenberg wrote:
> > > Of course I would appreciate it if my browser asked me "this transfer
> > > was interrupted, it may be a bug on the site, a network condition error
> > > or an anti-malware detecting dangerous content, what do you want to do,
> > > try again, try to continue, abort, keep it truncated ?" and that would
> > > be done.
> >
> > If that happened in N% of your sessions and that other browser wouldn't
> > annoy the user as much, users might find that as reason to just go to the
> > other instead...
>
> Sure and this has been used as an argument against user notifications
> for quite a while, but it's more of a matter of having the few remaining
> players agree on a strategy here. After all, they all managed to make it
> really painful to access sites behind expired certificates. After all, we
> now all suffer from the annoyingly stpuid GDPR banners on every site which
> announces that it will set a cookie to remember our refusal of cookies, is
> way more annoying than an occasional browser pop-up, and we're all forced
> to live with that.
>
> > > One of the problems with the state of the web today *is* that we try to
> > > focus too much on user experience and avoid as much as possible to
> mention
> > > possible breakage.
> >
> > I'm with you a 100% on this, but that doesn't actually help much.
> >
> > I claim the reason "we" are this sensitive is because how the browser
> > economy works. Users equals money to browsers so if you scare off your
> users
> > to make them go use another browser that doesn't show the scary warning
> or
> > is more okay with "broken" sites, the browser vendor lose money. They
> rather
> > keep the users and instead compromise on protocol strictness (or at least
> > hide some of the issues).
>
> Yes, I can understand this point, which is also where standards definition
> can help get all of them on the same boat for very specific stuff, without
> the fear of losing users.
>
> Cheers,
> Willy
>
>