jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] Removing headers from the response

From: Mark Thomas <markt_at_apache.org>
Date: Tue, 23 Dec 2014 15:02:59 +0000

On 23/12/2014 10:27, Stuart Douglas wrote:
>
>
> ----- Original Message -----
>> From: "Mark Thomas" <markt_at_apache.org> To:
>> jsr369-experts_at_servlet-spec.java.net Sent: Tuesday, 23 December,
>> 2014 8:31:13 PM Subject: [jsr369-experts] Re: [servlet-spec users]
>> Removing headers from the response
>>
>> On 23/12/2014 06:29, Eugene Chung(정의근) wrote:
>>>
>>> On Tue, Dec 23, 2014 at 8:29 AM, Stuart Douglas
>>> <sdouglas_at_redhat.com <mailto:sdouglas_at_redhat.com>> wrote:
>>>
>>> At the moment there does not seem to be a way to remove a header
>>> from the response. It might be expected that calling
>>> HttpServletResponse.setHeader("name", null) will accomplish
>>> this, however it does not seem to be explicitly specified in the
>>> spec or the javadoc.
>>>
>>> What does everyone think about adding some clarification to the
>>> javadoc that explicitly states that if setHeader is called with
>>> a null value then the header will be cleared?
>>>
>>> Stuart
>>>
>>>
>>> Is this behaviour normal in other WASes? Our implementation
>>> ignores 'null' value.
>>
>> So does Tomcat.
>>
>> What is the use case for this? If an application doesn't want a
>> header to be present, it shouldn't add it in the first place.
>
> The use case that I came across this was a user filter that did gzip
> compression. Our default servlet sets a content length, and then the
> filter changes the content length.

There are a whole bunch of issues if a Filter does anything to modify
the response body. I started to think about this here:
https://java.net/jira/browse/SERVLET_SPEC-25

For the compression use case, wrapping is the only solution that is
going to work in all cases.

> It is possible for the filter to
> also wrap the response to ignore the content length, but either way a
> set header call with a null value is currently undefined behaviour. I
> think it would be cleaner to specify what should happen in this case,
> it should either remove the header or throw an
> IllegalArgumentException.

I'd be fine with IAE for null (not zero length) values and null or zero
length header names.

Mark


>
> In Undertow setHeader with null will wipe the header, addHeader will
> do nothing, and containsHeader will return true if setHeader(null)
> had been called.
>
> Stuart
>
>
>>
>> There are also some added complications: - The container may well
>> add headers after the request has left the servlet and filter chain
>> (e.g. content-length). If the app requests that this header is
>> removed before the container adds it, is the container meant to
>> honour that request? - Removing some headers will result in a
>> response that is not valid HTTP/1.1. Should the container allow
>> this?
>>
>> I'm leaning towards stating that null values and null/zero length
>> names will be ignored. I'd be prepared to change my position to
>> allowing header removal if: a) a valid use case was presented b) it
>> is carefully specified w.r.t. the issues above and any others we
>> can think of.
>>
>> Mark
>>