> On Apr 25, 2017, at 10:49 AM, Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote:
>
> Let me summarize our dicussions on #getTrailers API.
> I. We will choose NeverReturnNull option.
>
> II. Trailer vs Trailers.
> SW> In RFC 7230, Appendix B. Collected ABNF, we have the followimg:
> SW> Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
> SW> chunked-body = *chunk last-chunk trailer-part CRLF
> SW> t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
> SW> trailer-part = *( header-field CRLF )
>
> SW> In 4.1.2 of RFC 7230, we have
> SW> A trailer allows the sender to include additional fields at the end
> SW> of a chunked message in order to supply metadata that might be
> SW> dynamically generated while the message body is sent, such as a
> SW> message integrity check, digital signature, or post-processing
> SW> status. The trailer fields are identical to header fields, except
> SW> they are sent in a chunked trailer instead of the message's header
> SW> section.
>
> SW> In 4.3 of RFC 7230, we have
> SW> The TE field-value consists of a comma-separated list of transfer
> SW> coding names, each allowing for optional parameters (as described in
> SW> Section 4), and/or the keyword "trailers".
>
> SW> So, look like "trailers" is a keyword used in TE.
> SW> And a trailer is a collection of headers.
>
> SW> Should we rename our API as
> SW> #getTrailerFields, #setTrailerFields or
> SW> #getTrailer, #setTrailer?
> SW> I prefer the former.
>
> GW> I still prefer #getTrailers, but if we have to change
> GW> then #getTrailerFields is second choice.
>
> We will choose #getTrailerFields, #setTrailerFields.
>
> III. The data structure for trailer.
> We will choose Map<String, String> with key stored in lower case.
> For getter, it is fine.
>
> For supplier, what would happen when supplier produce a key that is not lower case?
> Options:
> a) UpperException:
> throw IllegalStatusException
> b) ConvertLower:
> Convert the lower case implicitly
>
> Unless I hear otherwise, we will choose (b) ConvertLower here.
>
I have a second thought on this. In fact, we do not need to consider this case as header names are case-insensitive.
(see RFC 7230, section 3.2)
So, there is no further issue for III.
Shing Wai Chan
> Unless someone has strong objections, the above is the API we will choose for Servlet 4.0.
> Thanks.
> Shing Wai Chan