I think the following is simplest.
If getTrailerFields() is called before -1 is read on a request with non
zero content-length, then an IllegalStateException is thrown. Ie, don't
call the method if there is no chance headers will be available.
Then when it is allowable to be called we return null if there are no
headers or a map if there are.
If you want to distinguish the case that headers were possible, but none
were sent, then an empty map can be returned rather than null.
cheers
On 11 May 2017 at 15:47, Martin Mulholland <mmulholl_at_us.ibm.com> wrote:
>
>
>
> Stuart Douglas <sdouglas_at_redhat.com> wrote on 05/10/2017 06:40:18 PM:
>
> > From: Stuart Douglas <sdouglas_at_redhat.com>
> > To: jsr369-experts_at_servlet-spec.java.net
> > Date: 05/10/2017 06:41 PM
> > Subject: [servlet-spec users] [jsr369-experts] Re: Re: Re: Re: Re:
> > Trailer header implementation
> >
> > On Wed, May 10, 2017 at 4:48 PM, Greg Wilkins <gregw_at_webtide.com> wrote:
> > >
> > > On 10 May 2017 at 02:29, Shing Wai Chan <shing.wai.chan_at_oracle.com>
> wrote:
> > >>
> > >> We think that it is simpler to require the application to read all
> the way
> > >> to -1
> > >> before trailer fields are available through #getHeader.
> > >
> > >
> > > Great. But perhaps have the shortcut that trailers are also
> immediately
> > > available if there is no content to read, ie a content length of 0 is
> > > returned.
> >
> > How would this work in practice? In particular:
> > - If Content-Length is being used then the request cannot have trailers
> > - If chunking is being used but with no content we still can't be sure
> > when the trailers will arrive, they could potentially arrive in a
> > different packet than the initial request. I can't see any way to
> > reliably implement this that does not impose a cost on all chunked
> > requests, and even potentially break some use cases (as request
> > processing could not start until the first packet of the chunked
> > request body has been received so we know if the trailers should be
> > immediately available or not, which could break some tunneling use
> > cases where the client may be waiting for the start of the servers
> > response).
> >
> > Stuart
>
> I am willing to accept a getTrailerFields() api in the interest of moving
> on.
>
> The api needs to cover 4 scenarios:
> - Request is not chunked, no trailer will ever be received. Throw
> exception?
> - Request is chunked, but no trailers were received. Return empty map?
> - Request is chunked but we have not fully received the message yet so we
> don't know if trailer header will be provided. Return null?
> - When the trailer header has been received. Return the headers. For this
> I don't think we should say the app has to read all the data first, this
> just adds complexity for no gain. We just provide when we have them (so
> the
> message is fully received but app has not necessarily read all the data.
>
> thinking out loud should we have a new api
> - boolean areTrailerFieldsAvailable();
>
> the difficulty is how the app can block if it needs to wait for the
> trailer
> headers. If all message chunks have been received should
> getTrailerFileds() block
> until the message is fully received and the state of Trailer is known?
>
>
> Martin.
>
>
> >
> > >
> > >>
> > >> We feel the last remaining issue is whether to have a separate API for
> > >> reading trailer
> > >> fields or not. There are decent arguments for either approach.
> > >> We think using #getHeader (with reading to -1 proviso) is the simplest
> > >> approach
> > >> and also is more in keeping with the RFC 7230.
> > >>
> > >> In the spirit of compromise, please consider accepting this approach.
> > >
> > >
> > > I'm kind of -0 on this. If this is what it *really* takes to get
> trailer
> > > support, then OK.
> > >
> > > However, I do have concerns that the application will not be able to
> refuse
> > > to accept trailers and that applications that don't even consider
> trailers
> > > may be affected by suddenly clients using them.
> > >
> > > I think that trailer support is primarily needed not to allow existing
> > > headers to be sent late, but to enable new types of headers that can
> only be
> > > generated after the content is sent. Such trailers will require new
> code
> > > and thus I see very little benefit of using the existing headers API
> for
> > > them, but I do see several disadvantages of that approach.
> > >
> > > I think the API as currently specified in the draft is entirely
> workable and
> > > if there is no agreement of further changes, then I'd suggest we go
> forward
> > > as is.
> > >
> > > cheers
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
> >
>
>
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com