You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2020/01/13 22:50:18 UTC

[Bug 64073] New: CompressionConfig does not clear Content-Length header if already set

https://bz.apache.org/bugzilla/show_bug.cgi?id=64073

            Bug ID: 64073
           Summary: CompressionConfig does not clear Content-Length header
                    if already set
           Product: Tomcat 9
           Version: 9.0.30
          Hardware: PC
                OS: Mac OS X 10.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Connectors
          Assignee: dev@tomcat.apache.org
          Reporter: bclozel@pivotal.io
  Target Milestone: -----

This issue happens in the following case:

1. the connector is configured to compress HTTP responses
2. an application sets the following response header "Content-Length: 3000"
3. the CompressionConfig class checks that the request+response qualify for
compression
4. if they do, the response content length is set to "-1" (see:
https://github.com/apache/tomcat/blob/740e15e858993221fab4cbe025f408333255b785/java/org/apache/coyote/CompressionConfig.java#L326)
but the actual "Content-Length" header is never cleared.
5. the HTTP response has then both "Content-Length: 3000" and
"Transfer-Encoding: chunked" headers

It seems to be against the HTTP spec and is actively enforced by popular HTTP
clients, see
https://github.com/netty/netty/commit/8494b046ec7e4f28dbd44bc699cc4c4c92251729

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 64073] CompressionConfig does not clear Content-Length header if already set

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64073

--- Comment #2 from Andy Wilkinson <aw...@pivotal.io> ---
In this particular case (Spring Framework's reactive web stack adapted to
Tomcat), it's being set via TomcatHeadersAdapter [1]. It works directly with
MimeHeaders. I suspect that's the cause of the problem as I see that the
interception of setting Content-Length is done by org.apache.coyote.Response.

[1]
https://github.com/spring-projects/spring-framework/blob/6c2cb8ecf5d1d755f09aff80489aa8b6e49d70b1/spring-web/src/main/java/org/springframework/http/server/reactive/TomcatHeadersAdapter.java

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 64073] CompressionConfig does not clear Content-Length header if already set

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64073

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #1 from Mark Thomas <ma...@apache.org> ---
How is the application setting the header and exactly what values is it
passing? The call to set the content-length header should be intercepted so an
actual content-length header isn't present.

Tomcat checks the header name in a case insensitive manner but it doesn't check
for leading and/or trailing space. Could that be the issue here?

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 64073] CompressionConfig does not clear Content-Length header if already set

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64073

bclozel <bc...@pivotal.io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEEDINFO                    |RESOLVED

--- Comment #3 from bclozel <bc...@pivotal.io> ---
My apologies for the confusion, it's indeed an improper use of Tomcat's API on
our side. I've created
https://github.com/spring-projects/spring-framework/issues/24361 to track that
change.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org