On 8 September 2016 at 06:42, Edward Burns <edward.burns_at_oracle.com> wrote:
> If we choose "container wins" I propose the following then,
>
The container must win.
> 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 don't think they *must* be ignored, but they may be ignored.
For example Connection:close is a protocol thing and the container will add
that to the request if it must be there (because the request had it, the
request was http/1.0 and no content-length known etc.). But if the
application adds it when it is not necessary, then the container may choose
to keep it and respect it.
Similarly, if the application sets Transport-encoding:chunked, then that
may be removed it chunking is not available, but the container may chose to
chunk a response that may have otherwise been content-length framed.
So headers set by the application can be considered hints to application
preference, but may be overridden by the container as needed by protocol
requirements.
I think Stuarts text was necessary and sufficient:
"Containers may still add or modify headers before the response is
> committed. These will generally be headers that are required at a
> protocol level."
regards
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com