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? I think 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.
Given section 4.1.2 of RFC 2370, if a servlet container, prior to Servlet 4.0,
returns the trailer through #getHeader after inputStream returns -1,
we should not explicitly disallow it in Servlet 4.0.
In Servlet 4.0, we will return trailer fields through the new API #getTrailerFields().
Thanks.
Shing Wai Chan