[MAGNOLIA-2685] Setting headers multiple times does not work with all containers Created: 07/Apr/09  Updated: 04/Nov/15  Resolved: 04/Nov/15

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Magnolia International Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: jetty, jetty6, winstone
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

winstone or jetty6


Issue Links:
Relates
relates to MAGNOLIA-5536 Update test container to Jetty 9 Closed
dependency
is depended upon by MAGNOLIA-2686 Standalone bundle Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

This is currently visible with Winstone. For some reason, the servlet response is already committed when we try to add headers. (from the cache or gzip filters, possibly)
This might even only be occuring currently with the quickstart page.
This results in a blank page.

Winstone ignores such redundant headers (see below)
Jetty seems to just ignore the fact that they're redundant and adds them multiple times (although I assume we use setHeader and not addHeader?)

[Winstone 2009/04/07 12:35:28] - Cached filter chain available for cacheKey=FORWARD:URI:/.magnolia/pages/quickstart.html
[Winstone 2009/04/07 12:35:28] - Executing Filter: magnoliaFilterChain
[Winstone 2009/04/07 12:35:28] - Setting response character encoding to UTF-8
[Winstone 2009/04/07 12:35:28] - Setting the request encoding from UTF-8 to UTF-8
[Winstone 2009/04/07 12:35:28] - Setting response character encoding to UTF-8
[Winstone 2009/04/07 12:35:28] - ServletOutputStream flushed
[Winstone 2009/04/07 12:35:28] - Headers prepared for writing: [Server: Winstone Servlet Engine v0.9.10, Content-Type: text/html;charset=UTF-8, Connection: Close, Date: Tue, 07 Apr 2009 10:35:28 GMT, X-Powered-By: Servlet/2.5 (Winstone/0.9.10)]
[Winstone 2009/04/07 12:35:28] - Committing response body
[Winstone 2009/04/07 12:35:28] - Response: HTTP/1.1 200 OK
[Winstone 2009/04/07 12:35:28] - Header: Server: Winstone Servlet Engine v0.9.10
[Winstone 2009/04/07 12:35:28] - Header: Content-Type: text/html;charset=UTF-8
[Winstone 2009/04/07 12:35:28] - Header: Connection: Close
[Winstone 2009/04/07 12:35:28] - Header: Date: Tue, 07 Apr 2009 10:35:28 GMT
[Winstone 2009/04/07 12:35:28] - Header: X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
[Winstone 2009/04/07 12:35:28] - Written 0 bytes to response body
[Winstone 2009/04/07 12:35:28] - Header ignored after response committed - Content-Encoding: gzip 
WARN   info.magnolia.cms.util.RequestHeaderUtil RequestHeaderUtil.java(addAndVerifyHeader:68) RequestHandlerThread[#4] 2009-04-07 12:35:28,349 Unable to add response header Content-Encoding: gzip (uri:/.magnolia/trees/website.html userid:superuser)
[Winstone 2009/04/07 12:35:28] - Header ignored after response committed - Vary: Accept-Encoding 
WARN   info.magnolia.cms.util.RequestHeaderUtil RequestHeaderUtil.java(addAndVerifyHeader:68) RequestHandlerThread[#4] 2009-04-07 12:35:28,350 Unable to add response header Vary: Accept-Encoding (uri:/.magnolia/trees/website.html userid:superuser)
[Winstone 2009/04/07 12:35:28] - Header ignored after response committed - Content-Length: 3874 


 Comments   
Comment by Magnolia International [ 07/Apr/09 ]

Disabling the gzip filter seems to solve the issue, but after further investigation, the code below the gzip filter (i.e in gzipfilter, further filters, associated classes, and what winstone does of it) is apparently correct.
It seems the actual issue is that

  • winstone commits the response earlier than we expected
  • we do a forward in WebsiteTreeHandler after the response was committed; removing this forward also "apparently" solves the issue. The container should have thrown an IllegalStateException, so it's a two-fold issue: a bug in winstone (the spec actually says the ISE should be thrown), and a bug on our part, since we try to do a forward when a response was already committed.
    Investigating why winstone doesn't behave correctly here (or if the assumptions above are wrong)
Comment by Magnolia International [ 07/Apr/09 ]

one further strange thing - it seems the content of the website tree page is still output after the content of the quickstart page. The current code doesn't return after the forward; not sure it should, but maybe that's part of the problem too.

Comment by Magnolia International [ 09/Apr/09 ]

This might actually not be the case at all, but still winstone commits the response "too early".
I was able to run Magnolia with the current WebsiteTreeHandler and QuickstartPage with a patched version of Winstone. Investigating why it does what it does when forwarding.

Comment by Magnolia International [ 13/Nov/09 ]

Might be related to MAGNOLIA-2936 - see comment about the CacheResponseWrapper

Comment by Magnolia International [ 27/Nov/13 ]

This problem - or a similar one - also happens with Jetty 6 and the REST module. It just seems that most containers (Tomcat, Jetty 8, ...) simply buffer headers (or the whole response, for a bit longer than Jetty 6 or Winstone) and somehow "merge" redundant headers. I'm not sure this is per any spec - it sounds to me like we should do that ourselves (and/or not set it so eagerly in ContentTypeFilter ?)

Comment by Tobias Mattsson [ 15/Jan/14 ]

This is what the spec has to say:

A servlet can set headers of an HTTP response via the following methods of the HttpServletResponse interface:

  • setHeader
  • addHeader

The setHeader method sets a header with a given name and value. A previous header is replaced by the new header. Where a set of header values exist for the name, the values are cleared and replaced with the new value.

The addHeader method adds a header value to the set with a given name. If there are no headers already associated with the name, a new set is created.

Regarding HttpServletResponse.setContentType() the spec says:

The setCharacterEncoding, setContentType, and setLocale methods can be called repeatedly to change the character encoding.

Which is repeated in the javadoc:

This method may be called repeatedly to change content type and character encoding.

Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 03:39:06 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.