> On May 8, 2017, at 12:18 PM, Martin Mulholland <mmulholl_at_us.ibm.com> wrote:
>
> 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.
We have discussed this issue before [1].
In [1], we discuss what data structure to use to represent trailer.
MT raised similar issue as above and had proposed to use Map<String, List<String>>.
Let me paraphrase the discussion here.
Suppose user send two trailer
foo: v1, v2
foo: v3
Then MT proposes to have a map containing “foo” -> { “v1”, “v2”, “v3” } // a list with three element
GW has a concern about parsing the request to generate the list here.
But he is ok with Map<String, List<String>> if we allow the map to be “foo” -> { “v1, v2”, “v3” }
At that time, we agreed with a solution for using Map<String, String> in this case.
If we use Map<String, String>,
- for request, the container will aggregate multiple header with the same names into a String
- for response, then the caller needs to aggregate multiple header with the same names into a String
If we use Map<String, List<String>>,
- for request/response, then the caller use List<String> as value (even when there one header for a given name)
If there is any concern, then please let us know.
Thanks.
Shing Wai Chan
ps.
[1]
https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2017-04/message/69 <
https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2017-04/message/69>
>
>
> 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 themselves.
>
> 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.
>
> cheers
>
>
> On 8 May 2017 at 19:38, Martin Mulholland <mmulholl_at_us.ibm.com <mailto: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.
> OR
> (A) sets all headers at once (A) not allowing multiple values.
>
>
> 2. (a) App sets Trailer header
> OR
> (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.
>
>
> Thanks,
> Martin.
>
>
>
>
>
>
>
>
>
> From: Greg Wilkins <gregw_at_webtide.com <mailto:gregw_at_webtide.com>>
> To: jsr369-experts_at_servlet-spec.java.net <mailto: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
>
>
>
>
> Ed,
>
> I can definitely live with Ab and that is how Jetty has had it implemented currently.
>
> regards
>
>
> On 5 May 2017 11:37 pm, "Edward Burns" <edward.burns_at_oracle.com <mailto: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
>
> Trailers:
>
> header.
>
> 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.
>
> Thanks,
>
> Ed
> --
> | edward.burns_at_oracle.com <mailto:edward.burns_at_oracle.com>| office: +1 407 458 0017 <tel:%2B1%20407%20458%200017>
>
>
>
>
>
>
> --
> Greg Wilkins <gregw@webtide.com <mailto:gregw@webtide.com>> CTO http://webtide.com <http://webtide.com/>
>
>