-
Notifications
You must be signed in to change notification settings - Fork 851
Reject Transfer-Encoding in pre-HTTP/1.1 requests #8451
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
Merged
bneradt
merged 1 commit into
apache:master
from
bneradt:reject_transfer_encoding_in_pre_http1_1_requests
Oct 27, 2021
Merged
Reject Transfer-Encoding in pre-HTTP/1.1 requests #8451
bneradt
merged 1 commit into
apache:master
from
bneradt:reject_transfer_encoding_in_pre_http1_1_requests
Oct 27, 2021
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Author
|
The 8.1.x PR for this is: #8305 |
bryancall
approved these changes
Oct 27, 2021
zwoop
approved these changes
Oct 27, 2021
Per spec, Transfer-Encoding is only supported in HTTP/1.1. For earlier versions, we must reject Transfer-Encoding rather than interpret it since downstream proxies may ignore the chunk header and rely upon the Content-Length, or interpret the body some other way. These differences in interpretation may open up the door to compatibility issues. To protect against this, we reply with a 4xx if the client uses Transfer-Encoding with HTTP versions that do not support it.
19b7d3c to
81a72bf
Compare
pull bot
pushed a commit
to kalagxw/trafficserver
that referenced
this pull request
Oct 27, 2021
Per spec, Transfer-Encoding is only supported in HTTP/1.1. For earlier versions, we must reject Transfer-Encoding rather than interpret it since downstream proxies may ignore the chunk header and rely upon the Content-Length, or interpret the body some other way. These differences in interpretation may open up the door to compatibility issues. To protect against this, we reply with a 4xx if the client uses Transfer-Encoding with HTTP versions that do not support it.
bryancall
pushed a commit
that referenced
this pull request
Oct 27, 2021
Per spec, Transfer-Encoding is only supported in HTTP/1.1. For earlier versions, we must reject Transfer-Encoding rather than interpret it since downstream proxies may ignore the chunk header and rely upon the Content-Length, or interpret the body some other way. These differences in interpretation may open up the door to compatibility issues. To protect against this, we reply with a 4xx if the client uses Transfer-Encoding with HTTP versions that do not support it. (cherry picked from commit 6e50701)
zwoop
pushed a commit
that referenced
this pull request
Nov 9, 2021
Per spec, Transfer-Encoding is only supported in HTTP/1.1. For earlier versions, we must reject Transfer-Encoding rather than interpret it since downstream proxies may ignore the chunk header and rely upon the Content-Length, or interpret the body some other way. These differences in interpretation may open up the door to compatibility issues. To protect against this, we reply with a 4xx if the client uses Transfer-Encoding with HTTP versions that do not support it. (cherry picked from commit 6e50701)
Contributor
|
I don't know what's going on here, but the commit ID above is "empty", whereas 6e50701 does have the changes here. So I've cherry-picked that to 9.2.x. |
moonchen
pushed a commit
to moonchen/trafficserver
that referenced
this pull request
Mar 17, 2022
* asf/9.2.x: (50 commits) Updated ChangeLog Reject Transfer-Encoding in pre-HTTP/1.1 requests (apache#8451) Better TLS Secrets Truncation. (apache#8489) ssl_secret debug printing: print only the first 50 bytes (apache#8483) Define TS_HTTP_VALUE_BROTLI and TS_HTTP_LEN_BROTLI (apache#8477) Fix case of brotli (apache#8476) TSSslSecretSet: Update SSL_CTX TLS Secrets (apache#8368) Adding doc/README.md (apache#8420) Doc: fix typos in Strategy documentation (apache#8408) Refactors and promotes the Txn Control mechanism with Get() and Set() (apache#8428) tests: Add shbang to python scripts with a main (apache#8430) Remove empty tests/unit_tests directoy+makefile (apache#8429) Adds new API: TSVConnSslSniGet (apache#8313) rate_limit: convert to using TSVConnSslSniGet (apache#8414) Update the Multiplexer Docs for Multplexed HTTPS Connections (apache#8440) bigobj: use automake to build test utilities (apache#8441) Make sni.yaml errors cause an unrecoverable TS crash at startup. (apache#8208) Fix timeout checks of NetHandler::manage_active_queue() (apache#8287) Fix Multiplexer POST/PUT Body Handling (apache#8439) Document proxy.config.memory.max_usage (apache#8450) ...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Per spec, Transfer-Encoding is only supported in HTTP/1.1. For earlier
versions, we must reject Transfer-Encoding rather than interpret it
since downstream proxies may ignore the chunk header and rely upon the
Content-Length, or interpret the body some other way. These differences
in interpretation may open up the door to compatibility issues. To
protect against this, we reply with a 4xx if the client uses
Transfer-Encoding with HTTP versions that do not support it.