On 10/05/17 07:48, Greg Wilkins wrote:
>
> On 10 May 2017 at 02:29, Shing Wai Chan <shing.wai.chan_at_oracle.com
> <mailto: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.
+1.
> 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.
I'm -1 on this. My view aligns pretty much exactly with what Stuart has
already written.
> 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.
That works for me at this point.
Mark
>
> cheers
>
>
>
>
>
>
> --
> Greg Wilkins <gregw_at_webtide.com <mailto:gregw_at_webtide.com>> CTO
> http://webtide.com