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