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