Welcome to Servlet 4.0 on groups.io. I'll take this opportunity to resend the originial first message from jsr369-experts@..., and I'll update the references. EB> Hello Volunteers, EB> This

Let me summarize what we discuss in the previous emails. We agree on a) have the following API in HttpServletRequest: Map<String, String> getTrailerFields() b) there is no validation of trailer

Hi, EG members, Any comments on below? Thanks. Shing Wai Chan

I don't think isTrailerFieldsAvailable is necessary. An application has to wait until -1 is read (or a 0 length request) before calling any API else it will get an ISE. Then once it has waited, we

On April 21, 2017, we agree to choose NeverReturnNull option. In this case, Map<String, String> getTrailerFields() will never return null. (In general, we do not return null for API with Collection

SW> As MM (and MT) has suggested that we may like to add an API to check SW> whether trailer fields are available to read. So we may like to add SW> an API in HttpServletRequest as follows: SW>

Here is the javadoc for the proposed #isTrailerFieldsAvailable() API: /** * Return a boolean indicating whether trailer fields are available. * * This method returns true if and

<shing.wai.chan@...> wrote: What about if HTTP/2 is in use? Personally I think we should just drop this line, and just leave the following two lines (although I don't feel super strongly about

Can we send HTTP2/trailer when it is not chunked transfer encoding? I think we cannot. In section 8.1 of RFC 7540: 4. optionally, one HEADERS frame, followed by zero or more CONTINUATION frames

AT> Name change should be okay indeed. AT> On Tue, May 2, 2017 at 7:43 PM, Mark Thomas <markt@...> wrote:

<shing.wai.chan@...> wrote: HTTP/2 will never use chunked encoding. (8.1: HTTP/2 uses DATA frames to carry message payloads. The "chunked" transfer encoding defined in Section 4.1 of [RFC7230]

Ok. I agree that we should drop the chunked encoding condition in my previous proposal. In this case, I will revise the javadoc of #isTrailerFieldsAvailable as follows: * This method returns true

I think we need to say that the application had read to EOF or that there is no content. It would be a bit silly to force an app to read to EOF if content length is known to be 0 Cheers

I'd also add "or if the container knows that the underlying protocol does not support trailers". This would then meet the original use case I had in mind. Mark

+1

+1. To avoid the confusion, per discussion with Ed, I would rename the API as #isTrailerFieldsReady(). The API and the javadoc are as follows: /** * Return a boolean indicating whether

SW> To avoid the confusion, per discussion with Ed, I would rename the SW> API as #isTrailerFieldsReady(). The API and the javadoc are as SW> follows: SW> /** SW> * Return a boolean

[...] SD> This is wrong. Just because the response itself is US-ASCII the actual SD> values can be decoded into a different charset, which AFAIK all SD> servlet containers currently do and users

Can we have a quick release (b7?) of the API to maven central so we can build against it before voting. cheers -- Greg Wilkins <gregw@...> CTO http://webtide.com

This isn't quite what I had in mind. I was thinking that if the protocol didn't support trailers this method would always return true so the app could go ahead, call getTrailerFields() and get an