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.
> 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