MM> Based on the RFC I would expect the http component to make the trailer
MM> headers available immediately after it had read all of the data. However
MM> this is not the same as the application reading all of the data, so if we
MM> want the trailers to only be available after the app has read all the data
MM> that has to be a servlet container implementation.
We think that it is simpler to require the application to read all the way to -1
before trailer fields are available through #getHeader.
MM> Maybe it would be good to have a call to reach a consensus.
Normally we would like to have a conference call. But considering where we are in
the schedule, there is no time.
We feel the last remaining issue is whether to have a separate API for reading trailer
fields or not. There are decent arguments for either approach.
We think using #getHeader (with reading to -1 proviso) is the simplest approach
and also is more in keeping with the RFC 7230.
In the spirit of compromise, please consider accepting this approach.
Ed and Shing Wai Chan
> On May 9, 2017, at 9:59 AM, Martin Mulholland <mmulholl_at_us.ibm.com> wrote:
>
>
> Thank you,
> Martin Mulholland.
> WebSphere Application Server Web Tier Architect
> email: mmulholl_at_us.ibm.com
>
> IBM RTP, PO BOX 12195, 503/C227,
> 3039 Cornwallis Rd, RTP, NC 27709-2195
> t/l 444-4319, external (919)-254-4319
>
>
> Greg Wilkins <gregw_at_webtide.com> wrote on 05/09/2017 02:12:38 AM:
>
> > From: Greg Wilkins <gregw_at_webtide.com>
> > To: jsr369-experts_at_servlet-spec.java.net
> > Date: 05/09/2017 02:13 AM
> > Subject: [servlet-spec users] [jsr369-experts] Re: Re: Re: Trailer
> > header implementation
> >
> >> 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)
> >
>
> Have discussed this at length with my http component lead and these are
> our thoughts:
>
> An app using trailers would use the trailer headers to provide additional
> info about the data sent, the app would know this, expect the headers and
> know when and how to process them. If there is a same named header in the
> trailer, the getHeader api would still return the first and app would have
> to use getHeaders(String) to find the second.
>
> The idea here is to:
> 1. not unnecessarily expose the RFC in the servlet API.
> 2. not to impose uneccessary requirements on the http implementation.
>
> Based on the RFC I would expect the http component to make the trailer
> headers available immediately after it had read all of the data. However
> this is not the same as the application reading all of the data, so if we
> want the trailers to only be available after the app has read all the data
> that has to be a servlet container implementation. This maybe brings us back
> to having a getTrailers() option so we can block until the app has read all
> of the data but the reasons for not wanting getTrailers() are still there and
> even if we do this potentially the headers are still available using existing
> api's (they would in the IBM implementation). For this I also fall back to
> the concept that the app would only be interested in the trailer headers
> after reading all of the data, and it is not our place to deny access to
> headers once they are available. Instead we just say headers from the
> trailer section will be made available any time after they have
> been received.
>
> For the concurrent modification exception the IBM implementation always
> returns new enumerations so that is easily avoided.
>
> For extra code in getHeader API, in the IBM implementation this would not
> exist because we do not retain any header information, we always retrieve
> from the http component. I don't see any significant increase for http other
> than adding trailer headers to the header when they are received.
>
> Maybe it would be good to have a call to reach a consensus.
>
> Thanks,
> Martin.
>
>
>
>
>
>