> On May 10, 2017, at 11:11 AM, Mark Thomas <markt_at_apache.org> wrote:
>
> 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.
+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.
The following is from Section 4.1.2 of RFC 7230:
A sender MUST NOT generate a trailer that contains a field necessary
for message framing (e.g., Transfer-Encoding and Content-Length),
routing (e.g., Host), request modifiers (e.g., controls and
conditionals in Section 5 of [RFC7231]), authentication (e.g., see
[RFC7235] and [RFC6265]), response control data (e.g., see Section
7.1 of [RFC7231]), or determining how to process the payload (e.g.,
Content-Encoding, Content-Type, Content-Range, and Trailer).
So, one must not have authorization headers in trailer.
I do understand the concern of having trailer returning as header.
Look like, we should keep the existing #getTrailerFields API now.
Question: What happens when an user send an illegal trailer, like Transfer-Encoding, Content-Length, Host, authentication, etc, in mentioned above?
Should the servlet container returns those illegal header in trailer API it or ignore those it?
Since we are separating the trailer and header in getters, it is ok even if we do nothing for those header.
Any comment?
Thanks.
Shing Wai Chan
>
>> 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
>