Re: Cache control in trailers?

On Wed, Feb 03, 2021 at 10:18:48AM +0000, Poul-Henning Kamp wrote:
> --------
> Julian Reschke writes:
> > Am 03.02.2021 um 10:59 schrieb Poul-Henning Kamp:
> > > --------
> > > Julian Reschke writes:
> > >> Am 03.02.2021 um 10:48 schrieb Poul-Henning Kamp:
> > >>> --------
> > >>> Julian Reschke writes:
> > >>>
> > >>>> 1xx messages can not have a message body.
> > >>>
> > >>> The message body does not belong to the 142, it belongs to the trailer=
> > .
> > >>
> > >> Trailers in HTTP/1.1 require chunked encoding, thus a message body. You
> > >> can't send a message body absent a final status code message.
> > >
> > > This is not "Trailers in HTTP/1.1", so that is not relevant.
> > >
> > > This is a new HTTP extension which makes it possible to transmit a respo=
> > nse with body and header parts swapped.
> >
> > I still don't get how you deploy it in HTTP/1.1.
> 
> *Only* if a requestor lights whatever "bat-signal" we choose, can the
> responder send a 142, the chunked body and the headers, in that order.

Pity, no, please don't start to break all the representation. It's already
hard enough to make sure a stack works well for good cases and corner cases,
please let's not start to mix headers and body, or it will be a total mess.

1xx has no body and there are sufficient equipements in the wild relying
on that strong promise so that it does not change. And headers are unsuitable
for stream data for the essential reason that they usually need to be
bufferred and processed as a whole at once.

Willy

Received on Wednesday, 3 February 2021 11:25:06 UTC