[jsr369-experts] Re: [servlet-spec users] Re: Re: Trailer header implementation

From: Martin Mulholland <mmulholl_at_us.ibm.com>
Date: Mon, 8 May 2017 13:38:39 -0400

The prefreneces I have seen so far and adding my own:

Mark : Ba, Bb, Ab, Aa, C
Greg : Ba, Bb, C, Ab, Aa
Ed : Ab

So two main issues

1. (B,C) App sets one header at a time, allowing multiple values.
     (A) sets all headers at once (A) not allowing multiple values.

2. (a) App sets Trailer header
     (b) or container sets Trailer header (b).

For 1. I prefer B, because we should allow multiple values for a header
(similar setHeader and addHeader).

For 2. I pefer b, but, like Ed, not if we use the same method for two
functions. If we are stuck with one method I prefer a.

So this would leave me as Bb

If we can agree on these two points hopefully the rest will fall out.


From: Greg Wilkins <gregw_at_webtide.com>
To: jsr369-experts_at_servlet-spec.java.net
Date: 05/07/2017 08:18 AM
Subject: [servlet-spec users] [jsr369-experts] Re: Re: Trailer
header implementation


I can definitely live with Ab and that is how Jetty has had it implemented


On 5 May 2017 11:37 pm, "Edward Burns" <edward.burns_at_oracle.com> wrote:
Points to emphasize relative to Shing-wai's Section 2.

1. Not preventing developers from doing less than 100% transport
protocol compliant things.

We've never been in the business of preventing apps from doing things
that are not 100% protocol compliant. Especially with an area like
trailers, it's important to allow for interoperability with endpoints
that may or may not fully implement the underlying transport protocol
"correctly" with respect to the RFCs.

2. Avoiding creating single methods that do multiple things.

Both Ba and Bb feature a setTrailer method that does two things:

1. Appends a value to the



2. Appends a name/value pair to the trailer fields.

We've always avoiding introducing such complex and automatic APIs.

Considering both of these points, I strongly favor option Ab.

Also, we really need to close discussion on this because we're getting
very near the end. If we can't come to consensus by start of business
PDT next Friday, we should pull this feature from 4.0.


| edward.burns_at_oracle.com | office: +1 407 458 0017