> On Apr 19, 2017, at 1:51 PM, Greg Wilkins <gregw_at_webtide.com> wrote:
>
>
>
> How about:
>
> @return A map of trailers or null if the underlying transport used does not support trailers
>
> cheers
>
>
> On 20 April 2017 at 06:38, Mark Thomas <markt_at_apache.org <mailto:markt_at_apache.org>> wrote:
> On 14/04/17 19:51, Shing Wai Chan wrote:
> > I plan to add the following API:
> > ----------
> > HttpServletRequest:
> > /**
> > * Get the request trailer.
> > * This method can only be called after the application reads all
> > * the request content.
> > *
> > * @implSpec
> > * The default implementation returns null.
> > *
> > * @return A map of trailers or null if the request did not contain any
>
> That isn't quite what we discussed. My understanding was:
>
> - request body not chunked -> null
> - request body chunked -> Possible empty Map with trailer headers
What is the value of distinguish the null and empty map here? What is the use case for that?
If we want to distinguish null and empty above, then we have the following cases:
a) request body not chunked
b) request body chunked without TE trailer
c) request body chunked with TE trailer
The above discussion seems to indicate that (a) is null, and (b) is empty.
Do we really want to distinguish null and empty in #getTrailers()?
>
> > *
> > * @throws IllegalStateException if neither
> > * {_at_link javax.servlet.ReadListener#onAllDataRead} has been called nor
> > * an EOF indication has been returned from the
> > * {_at_link #getReader} or {_at_link #getInputStream}
> > *
> > * @since Servlet 4.0
> > */
> > default public Map<String, String> getTrailers() {
> > return null;
> > }
> >
> > HttpServletResponse:
> > /**
> > * Set the supplier of trailer headers.
> > * The supplier will be called within the scope of whatever thread/call
> > * causes the response content to be completed. Typically this will
> > * be any thread calling close() on the output stream or writer.
> > *
> > * The trailers that run afoul of the provisions of section 4.1.2 of
> > * RFC 7230 are ignored.
> > *
> > * @implSpec
> > * The default implementation is a no-op.
> > *
> > * @param supplier the supplier of trailer headers
> > *
> > * @since Servlet 4.0
> > */
> > default public void setTrailers(Supplier<Map<String, String>> supplier) {
>
> That needs to be Map<String,List<String>> to handle all of the RFC
> permitted cases. (The only use case I am aware of is Set-Cookie but it
> is a valid use case.)
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).
And RFC 6265 defines the HTTP Cookie and Set-Cookie header fields.
In other words, we cannot Set-Cookie in trailers.
Now, the question is:
Should we use Map<String, List<String>> in setTrailers as follows:
default public void setTrailers(Supplier<Map<String, List<String>> supplier);
And by symmetry, we may like to have
default Map<String, List<String>> getTrailers();
MT> I'd be happy with those but I'd prefer the Map to be Map<String,List<String>>.
GW> I'm a bit agnostic on the matter of Map<String,String> vs Map<String,List<String>>
GW> as regardless we will have to check strings for CSV anyway.
SW> So, I prefer the simpler Map<String, String> in this case.
While I prefer the simpler Map<String, String>, I would like to listen to opinion of the EG.
Shing Wai Chan
>
> Mark
>
>
>
>
> --
> Greg Wilkins <gregw@webtide.com <mailto:gregw@webtide.com>> CTO http://webtide.com <http://webtide.com/>