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.