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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@apache.org
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: [hidden email]
          Reporter: [hidden email]
  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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

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

Mark Thomas <[hidden email]> changed:

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

--- Comment #1 from Mark Thomas <[hidden email]> ---
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@apache.org
In reply to this post by Bugzilla from bugzilla@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=64073

--- Comment #2 from Andy Wilkinson <[hidden email]> ---
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@apache.org
In reply to this post by Bugzilla from bugzilla@apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=64073

bclozel <[hidden email]> changed:

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

--- Comment #3 from bclozel <[hidden email]> ---
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: [hidden email]
For additional commands, e-mail: [hidden email]