MM> I'll try one more time. Headers in the trailer part of the message are just normal
MM> headers, same as headers from the start of the message and there is nothing in the
MM> RFC which requires the http implementation to provide trailers as if they are
MM> something special and separate from these other headers. I spoke with our http
MM> component lead developer and he agrees with this assessment. To avoid the apparent
MM> confusion on the application side the Trailer header is provided to inform the
MM> recipient of the trailer headers to expect. We could use getTrailers() as a convenience
MM> method where we return the fields specified in the trailer header, but then we start
MM> exposing the RFC in our API which as we agreed in another thread we should no do.
MM> For getTrailers() to return everything form the trailer we need the http component
MM> to also provide that support which I do not think we should be imposing in the Servlet
MM> Specification.
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.
Shing Wai Chan
> On May 8, 2017, at 2:02 PM, Martin Mulholland <mmulholl_at_us.ibm.com> wrote:
>
>
> Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote on 05/08/2017 03:48:00 PM:
>
> > From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
> > To: jsr369-experts_at_servlet-spec.java.net
> > Date: 05/08/2017 03:48 PM
> > Subject: [servlet-spec users] [jsr369-experts] Trailer header implementation
> >
> > Let us discuss more on Section 3 in my previus email thread.
> >
> > Section 3: get trailer
> > MM> For an inbound trailer Section 4.1.2 of RFC2370 says:
> > MM> <quote>
> > MM> When a chunked message containing a non-empty trailer is received,
> > MM> the recipient MAY process the fields (aside from those forbidden
> > MM> above) as if they were appended to the message's header section.
> > MM> </quote>
> > MM> So in addition to getTrailers() we should make the trailer headers
> > MM> avaiable through the getHeader() api's and automatically add them when
> > MM> they become available (all inbound data is read).
> > MM> But this leads me to a concern that the RFC is a specification of how
> > MM> the transport layer should behave and it s not clear to me how much of
> > MM> this transport function should be exposed in the Servlet Specification.
> > MM> In the Servlet Spec we should not be making assumptions about how the
> > MM> transport layer works in which case we should not have a getTrailers()
> > MM> API but instead we just expose the headers using existing api's once all
> > MM> the data is read. That way we work whether or not the transport layer
> > MM> exposes the trailer headers or not.
> >
> > SW> On April 6, 2017, I proposed (in (a) StandardHeader option [1]) to use
> > SW> the standard header APIs as one of the option to retrieve trailer fields.
> > SW> This option was rejected in [2] and [3] as follows:
> > GW> with regards to request trailers, the key decision is when they are
> > GW> available, specially with async. Does the application have to read
> > GW> content
> > GW> to -1 or onAllDataRead before the trailers are available? Ithink yes.
> > GW> Then it does not make much sense to make them available via the normal
> > GW> header API and I think they need their own API.
> >
> > SD> I don't think this is a good approach. The trailers will not be
> > SD> available immediately, so this will basically result in the headers
> > SD> changing after the request has been read. I think it could be very
> > SD> confusing to the developer.
> >
> > SW> Since the trailer fields are processed "as if they were appended to the
> > SW> message's header section."
> > SW> Should trailer fields be available to get header API's, too?
> >
> > MT> I think not. I agree that having the return values for the standard
> > MT> header API change depending on whether the request is fully read or not
> > MT> is very likely to cause confusion. So +1 to GW and SD comments above.
> >
> > MM> I disagree, if the app reads the trailer header it knows which headers to
> > MM> re-read after the inbound data is fully read. Adding getTrailers()
> > MM> is imposing a level of support from the transport layer which to me is
> > MM> not appropriate.
> >
> > SW> Given section 4.1.2 of RFC 2370, if a servlet container, prior to Servlet 4.0,
> > SW> returns the trailer through #getHeader after inputStream returns -1,
> > SW>we should not explicitly disallow it in Servlet 4.0.
> >
> > SW> In Servlet 4.0, we will return trailer fields through the new API
> > SW> #getTrailerFields().
> >
>
> I'll try one more time. Headers in the trailer part of the message are just normal
> headers, same as headers from the start of the message and there is nothing in the
> RFC which requires the http implementation to provide trailers as if they are
> something special and separate from these other headers. I spoke with our http
> component lead developer and he agrees with this assessment. To avoid the apparent
> confusion on the application side the Trailer header is provided to inform the
> recipient of the trailer headers to expect. We could use getTrailers() as a convenience
> method where we return the fields specified in the trailer header, but then we start
> exposing the RFC in our API which as we agreed in another thread we should no do.
> For getTrailers() to return everything form the trailer we need the http component
> to also provide that support which I do not think we should be imposing in the Servlet
> Specification.
>
> Thanks,
> Martin.
>
>
>
>