If getTrailerFileds() is called before -1 is read on the request, why
would we throw an exception if the headers have already been received?
From: Greg Wilkins <gregw_at_webtide.com>
To: jsr369-experts_at_servlet-spec.java.net
Date: 05/11/2017 09:55 AM
Subject: [servlet-spec users] [jsr369-experts] Re: Re: Re: Re: Re:
Re: Re: Trailer header implementation
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