OK, I agree with this api:
void setTrailerFields(Supplier<Map<String, String>>)
we made need to say that with this api you cannot include a "," in a
header value
but given the RFC doesn't appear to have a concern with that then no
biggie.
Thanks,
Martin.
Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote on 05/08/2017 06:01:06
PM:
> From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
> To: jsr369-experts_at_servlet-spec.java.net
> Date: 05/08/2017 06:01 PM
> Subject: [servlet-spec users] [jsr369-experts] Re: Re: Re: Re: Re:
> Re: Re: Trailer header implementation
>
> On May 8, 2017, at 2:33 PM, Martin Mulholland <mmulholl_at_us.ibm.com>
wrote:
>
>> I may be wrong but if you use this approach:
>>
>> void setTrailerFields(Supplier<Map<String, String>>)
>>
>> I am not sure how you can reliably parse the value String into
>> multiple header values because, as I understand it, the header value
>> can include petty much any character.
>>
>> Similarly not sure how an app could reliablly parse inbound trailers
>> if we aggregate for multiple inbound.
>
> We have discussed this issue before. For your convenience, let me
> put my previous argument below:
> Section 3.2.2 of RFC 7230:
> A sender MUST NOT generate multiple header fields with the same field
> name in a message unless either the entire field value for that
> header field is defined as a comma-separated list [i.e., #(values)]
> or the header field is a well-known exception (as noted below).
> Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
> appears multiple times in a response message and does not use the
> list syntax, violating the above requirements on multiple header
> fields with the same name. Since it cannot be combined into a
> single field-value, recipients ought to handle "Set-Cookie" as a
> special case while processing header fields. (See Appendix A.2.3
> of [Kri2001] for details.)
> Section 4.1.2 of RFC 7230:
> A sender MUST NOT generate a trailer that contains a field necessary
> for message framing (e.g., Transfer-Encoding and Content-Length),
> routing (e.g., Host), request modifiers (e.g., controls and
> conditionals in Section 5 of [RFC7231]), authentication (e.g., see
> [RFC7235] and [RFC6265]), response control data (e.g., see Section
> 7.1 of [RFC7231]), or determining how to process the payload (e.g.,
> Content-Encoding, Content-Type, Content-Range, and Trailer).
>
> In other words, all the trailer header values can be common-
> separated. Hence, we can combine into one.
>
>
>> Using Map<String, List<String>> alleviates this problem but is not
>> great when you only want one value.
>
> If we use List, then there is no need to combine, but is not great
> as you mentioned above.
>
>
>> Existing api's setHeader, addHeader, getHeader, getHeaders etc work
well.
>
> Not sure whether it is a good idea to have non-List version of the
> API at the same time.
>
> Shing Wai Chan
>
>
> 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
>
>
> Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote on 05/08/2017 04:26:39
PM:
>
> > From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
> > To: jsr369-experts_at_servlet-spec.java.net
> > Date: 05/08/2017 04:27 PM
> > Subject: [servlet-spec users] [jsr369-experts] Re: Re: Re: Re: Re:
> > Trailer header implementation
> >
> > 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
> >
> >
> >
> > 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> 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>
> > 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
> >
> >
> >
> >
> > 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>
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| office: +1 407 458 0017
> >
> >
> >
> >
> >
> >
> > --
> > Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
> >