Content-Type is set:

1. in JiraEncodingFilter to text/html; charset=UTF-8
2. in StreamsActivityServlet to application/atom+xml

Not sure if we could disable JiraEncodingFilter.

These are my changes to atlassian-gzipfilter. I got a failing test that replicates the JIRA problem
https://bitbucket.org/atlassian/atlassian-gzipfilter/branch/issue/JRA-42660-no-empty-content-encoding?dest=stable-1.x#diff

I'd recommend a proper fix, ie. deferring the headers until the response is committed.

I have a version of atlassian-gzipfilter with deferred headers, it indeed solves the activity problem but introduces another.

In the Jira filter chain Gzip filter is not the first one, t's underlying response is also wrapped. When servlet does dispatcher.include(), the original response for the first servlet is replaced with ApplicationHttpResponse with include flag turned on. This prevents headers to be set, see section 9.3 of servlet 3.0 specs

9.3 The Include Method
The include method of the RequestDispatcher interface may be called at any time.
The target servlet of the include method has access to all aspects of the request
object, but its use of the response object is more limited.
It can only write information to the ServletOutputStream or Writer of the response
object and commit a response by writing content past the end of the response buffer,
or by explicitly calling the flushBuffer method of the ServletResponse interface.* It
cannot set headers* or call any method that affects the headers of the response, with
the exception of the HttpServletRequest.getSession() and
HttpServletRequest.getSession(boolean) methods. Any attempt to set the
headers must be ignored, and any call to HttpServletRequest.getSession()
or HttpServletRequest.getSession(boolean) that would require adding a
Cookie response header must throw an IllegalStateException if the response
has been committed.

Gzip filter has no control over the moment when include is called, the original response get replaced straight in the beginning of the chain (see ApplicationDispatcher.wrapResponse). Therefore, when time comes to set the headers, gzip filter is unable to do it.

I can see two solutions:

• set gzip filter the first in JIRA
• do not change gzip filter and prevent Content-Type to be set multiple times

I don't know. Sorry.

With regards to Nginx, it happens when proxying JIRA when gzip is enabled, gzip_types containing application/atom-xml, and gzip_proxied enabled. All due to the Content-Encoding header empty.

Does this happen with Apache as well as nginx?