New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strip the Content-Length header after decompressing HTTP requests #2271

Merged
merged 1 commit into from Feb 10, 2018

Conversation

Projects
None yet
2 participants
@arteam
Member

arteam commented Feb 10, 2018

Problem:

BiDiGzipHandler decompresses HTTP requests with compressed data, so for the handlers down the stack the content looks like plain-text data and they don't need to bother with decompressing in the application level logic. Unfortunately, the handler doesn't strip the original Content-Length header from requests, and requests return the content length of compressed content instead of uncompressed. This can create confusing situations for applications that check the length of requests for future processing. A classic example is a reverse proxy handler which parses a request, enriches it, and sends it to an origin server for processing. In this case, the proxy handler will send plain data to the origin server, but with a misleading Content-Length header and the origin will reject the request as malformed.

Solution:

A solution is to strip the Content-Length header from the request and override the getContentLength method of HttpServletRequest to specify it as an unknown. In this case the proxy handler will pass the request as chunked to the origin server (albeit without the Transfer-Encoding header), and it will be correctly handled. This seems to be a correct behaviour, because we don't know the length of
decoded content beforehand.

Result:

Transparent handling of compressed HTTP requests in Dropwizard applications.
Resolves #2268

Strip the Content-Length header after decompressing HTTP requests
`BiDiGzipHandler` decompresses HTTP requests with compressed data, so
for handlers down the stack the content looks like a plain-text data
and they don't need to bother with decompressing in the application
level logic. Unfortunately, the handler doesn't strip the original
`Content-Length` header from requests, and requests return the content
length of compressed content instead of uncompressed. This can create
confusing situations for applications which check the content length
of requests for future processing. A classic example, a reverse proxy
handler which parses a request, enriches it and sends it to an origin
server. In this case, the proxy handler will send plain data to the
origin server, but with a misleading `Content-Length` header and the
origin server will reject the request as malformed.

A solution is to strip the `Content-Length` header from the request
and override the `getContentLength` method of `HttpServletRequest` to
specify an unknown length. In this cases the proxy handler will pass
the request as chunked to origin server (albeit without the
`Transfer-Encoding` header), and it will be correctly handled. This
seems to be a correct behaviour, because we don't know the length of
decoded content beforehand.
@jplock

jplock approved these changes Feb 10, 2018

@jplock jplock added this to the 1.3.0 milestone Feb 10, 2018

@jplock jplock added the bug label Feb 10, 2018

@jplock jplock merged commit dd097e8 into master Feb 10, 2018

5 checks passed

ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@jplock jplock deleted the strip-content-length branch Feb 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment