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

From: Martin Mulholland <mmulholl_at_us.ibm.com>
Date: Mon, 8 May 2017 15:18:04 -0400

My bad, agree we should not be enforcing the RFC in our API's so app has
to set the trailer header, and we don't look at its value or enforce any
restrictions on what fields are set in the trailer.

For Ab this leaves us with this API:

void setTrailerFields(Supplier<Map<String, String>>)

My concern here is that the trailer fields are are just normal headers
sent in the trailer section of the response and it should be possible to
include a header multiple times.

Thank you,
Martin Mulholland.
WebSphere Application Server Web Tier Architect
email: mmulholl_at_us.ibm.com

IBM RTP, PO BOX 12195, 503/C227,
3039 Cornwallis Rd, RTP, NC 27709-2195
 t/l 444-4319, external (919)-254-4319

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

i think the fundamental question here is should the container bhee trying
to enforce/assist with compliance to the RFC - ie should the container
manage the relationship between the Trailers header and the trailers

Ed's point of view is that we don't enforce/assist with RFC correctness on
many other fields and the API can be used to create many non-compliant
messages. If we agree with that point of view then the existing proposed
API (Ab) is the natural result.

If we don't agree with that point of view, then the container needs to
help somehow. Ba appears to be the winner there.

I'm sitting on the fence as to if I agree with Ed or not. But as time
is short, then I think Ed's point of view does have the appeal of
simplicity and inertia.

On 8 May 2017 at 19:38, Martin Mulholland <mmulholl_at_us.ibm.com> wrote:
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
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com