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

From: Martin Mulholland <mmulholl_at_us.ibm.com>
Date: Mon, 8 May 2017 17:02:41 -0400

Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote on 05/08/2017 03:48:00

> 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
> 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
> MM> the recipient MAY process the fields (aside from those
> MM> above) as if they were appended to the message's header
> 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
> MM> they become available (all inbound data is read).
> MM> But this leads me to a concern that the RFC is a specification of
> MM> the transport layer should behave and it s not clear to me how much
> MM> this transport function should be exposed in the Servlet
> MM> In the Servlet Spec we should not be making assumptions about how
> MM> transport layer works in which case we should not have a
> MM> API but instead we just expose the headers using existing api's once
> MM> the data is read. That way we work whether or not the transport
> MM> exposes the trailer headers or not.
> SW> On April 6, 2017, I proposed (in (a) StandardHeader option [1]) to
> SW> the standard header APIs as one of the option to retrieve trailer
> SW> This option was rejected in [2] and [3] as follows:
> GW> with regards to request trailers, the key decision is when they
> GW> available, specially with async. Does the application have to
> GW> content
> GW> to -1 or onAllDataRead before the trailers are available? Ithink
> GW> Then it does not make much sense to make them available via the
> 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
> SD> changing after the request has been read. I think it could be
> SD> confusing to the developer.
> SW> Since the trailer fields are processed "as if they were appended to
> 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
> MT> is very likely to cause confusion. So +1 to GW and SD comments
> 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
> 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
something special and separate from these other headers. I spoke with our
component lead developer and he agrees with this assessment. To avoid the
confusion on the application side the Trailer header is provided to inform
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
to also provide that support which I do not think we should be imposing in
the Servlet