Mark Thomas <markt_at_apache.org> wrote on 05/04/2017 06:57:55 AM:
> From: Mark Thomas <markt_at_apache.org>
> To: jsr369-experts_at_servlet-spec.java.net
> Date: 05/04/2017 06:58 AM
> Subject: [servlet-spec users] [jsr369-experts] Re: Re: Re: Trailer
> header implementation
>
> On 04/05/17 01:01, Shing Wai Chan wrote:
> > Let us summarize what we discuss on the trailer implementation.
>
> <snip/>
>
> > ---
> > MT> 2. What happens if setTrailerFields() is called after the response
is
> > MT> committed?
> >
> > GW> Good question. We can go either: If when it is set, the response
is
> > committed
> > GW> with a transport mode that cannot support trailers then an
> > illegalStateException
> > GW> can be thrown; alternately we can just never call the supplier to
> > get the trailers.
> > GW> Jetty currently does the later, but I can see reasons for the
former.
> >
> > MM> It is just the trailer header which must be sent before the
response is
> > MM> committed so in theory we could accept this after commit if the
> > MM> trailer header was provided and sent before commit. This
complicates
> > things
> > MM> but does not seem a unreasonable expectation from an app.
> >
> > MT> Throw an IllegalStateException
> > MT> But. It also depends on 1). If we don't have to set the Trailers
> > MT> header it may still be possible to send the trailer fields
> >
> > GW> +1
> >
> > +1
> >
> > ---
> > MT> 3. What happens if setTrailerFields() is called and trailer fields
are
> > MT> not supported (HTTP 0.9, HTTP 1.0, some proxy protocols, etc.)?
> >
> > GW> Same as above.
> >
> > MM> Difficulty is if the trailer fields include some valid headersand
some
> > MM> invalid headers so I vote for just ignoring the invalid ones.
> >
> > MT> Throw an IllegalStateException
> >
> > GW> +1
> >
> > +1
>
> <snip/>
>
> > MT> Do we need a boolean areTrailerFieldsSupported() method?
> >
> > Not at this point unless (1) needs this.
>
> My thinking here was that we don't want to force users to trigger an
> exception to find out whether an action is valid or not.
>
> For 2, they can check if the response is committed so no problem there.
>
> For 3, they have no way to determine if trailers are supported apart
> from trying it and catching the exception. That seems wrong to me.
>
> Therefore, I think we do need a areTrailerFieldsSupported() method.
>
> Mark
>
We need to be careful here, I think it would be useful to an app to
understand whether or not a TE header indicated trailers headers are
"supported" because it may change how it processes the request
but even if the TE header indicates that trailer headers are not supported
the app may still want to send trailer headers. We could leave it to the
app to
look at the TE header or provide a convenience method as Mark suggested,
but
not sure Mark has the right name, maybe:
boolean isTrailerFieldSupportSpecified()
Thanks,
Martin.