jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] Re: Re: Trailer header implementation

From: Greg Wilkins <gregw_at_webtide.com>
Date: Tue, 9 May 2017 08:12:38 +0200

On 8 May 2017 at 23:30, Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote:

> I have discussed this with Ed. We are both ok to use existing request
> header API
> for request trailer. And no new API is added for request trailer.
>
> In this case, we will only add API for response trailer.
>
> Is this ok for other EG?
> Please let us know.
>

The good thing about this approach is that existing applications that
consult headers after reading content will just work with trailers.

The bad thing about this approach is that existing applications that
consult headers after reading content will just work with trailers.

Also it will be tough for applications to enforce compliance with the RFC
for the Trailers header. They will have to check before all content is
written for the absence of a header, then check again afterwards for it's
presence. Difficult if the name is both a header and a trailer.

Also, when are the trailers added to the header results? when the container
has read the entire message or only once the application has read the -1 ?
    Async apps will have to be careful about concurrent modification on
header enumerations.

Finally, such an approach will put a tiny bit of extra complication in the
implementation of the normal getHeader API, which is probably executed
billions of times every day (if not hour). The 99.9999% of applications
that don't care about trailers are each going to pay a tiny cost, which
combined will be a non trivial amount of CPU/power etc. Better to have
trailers separate, so only the few applications that wish to allow trailers
need use the API.

So on balance, I'd prefer to keep the trailers out of the headers API.
However, I'm not opposed to using the same style API (even with retro
enumerations) for getTrailerNames(), getTrailer(String) and
getTrailerValues(String)

regards




-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com