jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] [SPEC-159] HttpServletResponse.setHeader() and null

From: Stuart Douglas <sdouglas_at_redhat.com>
Date: Thu, 8 Sep 2016 07:19:41 +1000

On Thu, Sep 8, 2016 at 6:42 AM, Edward Burns <edward.burns_at_oracle.com> wrote:
>>>>>> On Wed, 7 Sep 2016 16:46:12 +0100, Mark Thomas <markt_at_apache.org> said:
>
> EB> Do we specifically need to account for the case of collision between a
> EB> header set by the app and one that is set by the container? If so, we
> EB> must decide who wins, the container or the app. I judge the app should
> EB> win. If so, the text could be rewritten as:
>
> EB> Containers retain the right to add or modify headers before the
> EB> response is committed. If a header is explicitly set by the
> EB> application, containers must not change the header set in this way.
>
> EB> I don't see the need for a statement about what sorts of headers the
> EB> container generally needs to add.
>
> EB> Thoughts?
>
> MT> -1. The container should win. It will only be setting protocol required
> MT> headers and those are something the application should not be
> MT> interfering with.
>
> If we choose "container wins" I propose the following then,

We have to choose 'container wins', otherwise application set headers
can completely break the connection (e.g. setting a wrong content
length, setting transfer-encoding for fixed length responses etc).

>
> Containers retain the right to add or modify headers before the response
> is committed. Any changes to such headers made by the application must
> be ignored by the container.

I prefer the original text I proposed. I think the message above is
kinda redundant, basically it amount to 'if the container decides to
do something, the container must do that thing'.

Stuart

>
> Ed
>
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017