On Thu, May 11, 2017 at 5:41 AM, Shing Wai Chan
<shing.wai.chan_at_oracle.com> wrote:
>
>> 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.
We can't rely on potentially malicious clients following the RFC. Also
it is not just the authorization header field that is the issue, there
are lots of headers that are used to transfer information from a load
balancer to a backend server where there is an assumption that the
load balancer will strip/overwrite any of these headers present in the
client request so that they can be trusted.
If the proxy is not smart enough to also strip it from the HTTP
trailers then you can have a situation where a remote client can send
a 'trusted' header straight through to the application (a good example
of this sort of header is SSL_CIPHER and related headers, which Tomcat
and Undertow (and possibly others) can use to forward SSL information
from a load balancer that is terminating the SSL connection to a
backend application. If this was sent as a trailer you could
potentially trick an application into thinking that SSL is in use even
though it is not)
>
> 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?
I am ok with doing nothing. The correct thing to do would be to
respond with a 400, but we are a bit late in the request processing to
mandate that, and I can't see this doing any hard as there is a
seperate API for trailers.
Stuart
>
> 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
>>
>