Stuart Douglas <sdouglas_at_redhat.com> wrote on 05/10/2017 06:50:20 PM:
> From: Stuart Douglas <sdouglas_at_redhat.com>
> To: jsr369-experts_at_servlet-spec.java.net
> Date: 05/10/2017 06:51 PM
> Subject: [servlet-spec users] [jsr369-experts] Re: Re: Re: Re: Re:
> Trailer header implementation
>
> 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
I agree with "doing nothing", we don't restrict what trailers the app
sends
and we just provide to the app whatever we get. Well, actually we are not
doing
do nothing, we are providing a separate api for the app to get the
trailers adresses
this problem to some extent.
Also the RFC2370 is a spec for an http implementation and, as as we agreed
before, the servlet container is not responsible for ensuring RFC 2370
compliance.
Martin.
>
> >
> > 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
thatapproach.
> >>>
> >>> 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
> >>
> >
>