[jsr369-experts] Trailer header implementation

From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
Date: Mon, 8 May 2017 12:48:00 -0700

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().

Shing Wai Chan