On 31/12/2014 13:31, Greg Wilkins wrote:
>
> On 23 December 2014 at 11:27, Stuart Douglas <sdouglas_at_redhat.com
> <mailto:sdouglas_at_redhat.com>> wrote:
>
> In Undertow setHeader with null will wipe the header, addHeader will
> do nothing, and containsHeader will return true if setHeader(null)
> had been called.
>
>
> Jetty does the same. Or to be more precise a set header will remove the
> previous value and then ignore the null and not set a new value.
>
> While I don't see any massive use-case to allow removing headers, I
> don't see a good reason for not doing it either. Apps can break things
> just as easily by adding/setting headers as by removing them, so no
> extra danger there. Plus they have the power to wrap if they want, so
> nothing new.
>
> So I don't think we need a new delete header method, but I do think we
> should define what a null value does. I think that the behaviour as
> described by Stuart is reasonable.
I know I previously said I'd be fine with IAE in all cases. I'd be fine
with something along the lines of the above as well but there are a few
details I'd change:
setHeader(null, anything) -> IAE or NO-OP
(slight preference for NO-OP on reflection)
setHeader(X, null) -> removes header
setHeader(X, "") -> adds header with empty value
Note: If the header has been removed, containsHeader(X) would return false
containsHeader(null) would always return false
I'd also add something along the lines of the following clarification,
e.g. to the setHeader() Javadoc.
Note: Containers may still add headers (e.g. for specification
compliance) after the request/response has returned to the container.
Where these headers are not required for specification compliance the
container should provide a container specific option to not add the header.
Mark