Re: Cache control in trailers?

------ Original Message ------
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Greg Wilkins" <gregw@webtide.com>; "Stefan Eissing" 
<stefan.eissing@greenbytes.de>; "Willy Tarreau" <w@1wt.eu>; "Ryan 
Sleevi" <ryan-ietf@sleevi.com>; "Martin Thomson" <mt@lowentropy.net>; 
"ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Sent: 5/02/2021 12:52:39 pm
Subject: Re: Cache control in trailers?

>--------
>Adrien de Croy writes:
>
>>  at the cost of the ability to block on any metadata without having to=20
>>  spool the entire resource (and delay it).
>
>Uhm, we must be talking waaaaay past each other here...
>
>The scenario where trailes offer low hanging fruit is:
>
> client:   server:
> -------------------------------------------------------
> request -->
>
>    start production of dynamic response body
>    since we cannot know what it will be, we
>    have to spool it locally first.
>    chew
>    chew
>    chew 
>    chew 
>    AhA!  Now we are certain what metadata properties
>    the response should have
>    produce headers
>    send headers
>    send body
> receive headers
> chugga
> chugga
> chugga
> chugga
> chugga
> finish receiving body
>

not in my experience. All the scripts I've seen returning content 
explicitly set Content-Type first before they start spewing content, and 
it's streamed out, the servers don't have to spool at all.

What sort of metadata is it envisioned would require waiting until the 
end of transmission to set and be based on the entire content?  And have 
to be sniffed by the server?  I can't think of any.  We've had 
discussions in the past about clients sniffing response message bodies 
and it was decided it was a bad thing for security reasons, but I think 
everyone still does it or the internet breaks.

Adrien

>
>Today nobody supports trailers, so the server is forced to spool
>the body locally, so the transmission can only start once the
>entire, possibly very large body has been produced.
>
>With my proposal:
>
> client:   server:
> -------------------------------------------------------
> request -->
>
>    Hmm, we need trailers
>    send new 3xx code, saying metadata comes last
> receive 3xx
>    start production of dynamic response body
>    send stuff as soon as it is produced
>    chew
> receive body  chew
>    chew 
> receive more body chew 
>    send final chunk
>    AhA!  Now we know what metadata properties the response should have
> receive end of body
>    produce headers
>    send headers
> receive headers
> act on headers & body
>
>In short, the spooling is moved from the server to the client,
>which means the transmission of it overlaps the production,
>and the server gets to determine the metadata as production
>progresses.
>
>--
>Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>phk@FreeBSD.ORG         | TCP/IP since RFC 956
>FreeBSD committer       | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by incompetence.
>

Received on Friday, 5 February 2021 01:33:25 UTC