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
>