For an inbound trailer Section 4.1.2 of RFC2370 says:
<quote>
When a chunked message containing a non-empty trailer is received,
the recipient MAY process the fields (aside from those forbidden
above) as if they were appended to the message's header section.
</quote>
So in addition to getTrailers() we should make the trailer headers
available
through the getHeader() api's and automatically add them when they become
available (all inbound data is read).
But this leads me to a concern that the RFC is a specification of how
the transport layer should behave and it s not clear to me how much of
this transport
function should be exposed in the Servlet Specification. In the Servlet
Spec we
should not be making assumptions about how the transport layer works in
which case
we should not have a getTrailers() API but instead we just expose the
headers using
existing api's once all the data is read. That way we work whether or not
the transport
layer exposes the trailer headers or not.
Thank you,
Martin Mulholland.
From: Mark Thomas <markt_at_apache.org>
To: jsr369-experts_at_servlet-spec.java.net
Date: 05/03/2017 07:03 AM
Subject: [servlet-spec users] [jsr369-experts] Trailer header
implementation
Hi,
I've been working on trailer header implementation. No particular issues
with requests but the response implementation is identifying a lot of
questions.
The first one is triggered by Section 4.4 for RFC 7230:
<quote
When a message includes a message body encoded with the chunked
transfer coding and the sender desires to send metadata in the form
of trailer fields at the end of the message, the sender SHOULD
generate a Trailer header field before the message body to indicate
which fields will be present in the trailers. This allows the
recipient to prepare for receipt of that metadata before it starts
processing the body, which is useful if the message is being streamed
and the recipient wishes to confirm an integrity check on the fly.
</quote>
1. How is the container meant to construct the Trailer header field? The
point of using a supplier was so the header names and values did not
have to be known when the response was committed. However, section 4.4
requires that the names are known.
The remaining questions are a little simpler:
2. What happens if setTrailerFields() is called after the response is
committed?
3. What happens if setTrailerFields() is called and trailer fields are
not supported (HTTP 0.9, HTTP 1.0, some proxy protocols, etc.)?
4. What happens if setTrailerFields() is called multiple times?
5. What happens if setTrailerFields() is called with a null Supplier?
My current thinking:
1) Do we ignore the 'SHOULD' or do we change the API? I'm leaning
towards changing the API on the basis that if we are going to add
trailer support we should do it as correctly as possible.
2) Throw an IllegalStateException
But. It also depends on 1). If we don't have to set the Trailers
header it may still be possible to send the trailer fields
3) Throw an IllegalStateException
4) Use the most recent Supplier
5) Allow it and protect against any possible NPE in the container
Of these, 1) is the most serious to address. After that, 2) & 3) since
the application has no way to tell if this is going to happen. Do we
need a boolean areTrailerFieldsSupported() method?
Mark