Be strict on invalid characters in request headers. #1785
Merged
Conversation
This file contains 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
This includes potential security problems (newline characters) as well as simple non-ASCII characters including international characters and emoji. Closes #891
|
FYI @nfuller this is a behavior change! |
JakeWharton
added a commit
that referenced
this pull request
Aug 3, 2015
Be strict on invalid characters in request headers.
amartinz
pushed a commit
to NamelessRom/android_external_okhttp
that referenced
this pull request
Jun 30, 2016
This relaxes some validation logic newly introduced in the version of OkHttp used in N. This change leaves the character code validation stricter than it was in M by still preventing control codes like \n, \r, backspace and delete. It does allow developers to pass Java characters > 7F to addRequestProperty() and also receive headers from servers which contain characters > 7F. Android's HttpURLConnection does not follow the HTTP spec as it encodes request header values and interprets response headers as UTF-8 and not ISO-8859-1. If a server is expecting or sending ISO-8859-1 encoded characters >7F in headers then these will still be corrupted or misinterpreted by Android. However, this has been the behavior since L and is not changed here. The OkHttp change which caused characters >7F to generate an IllegalArgumentException and partially reverted here: square/okhttp#1785 See also: square/okhttp#1998 square/okhttp#2016 for recent upstream bugs. Bug: 28867041 Bug: https://code.google.com/p/android/issues/detail?id=210205 (cherry picked from commit 75687ca5ae54f417afb4c02ba04767da6786d829) Change-Id: Ib640b58addff4c0c4eac589c77eb74a6bd6b3ec2
amartinz
pushed a commit
to NamelessRom/android_external_okhttp
that referenced
this pull request
Jun 30, 2016
This reapplies AOSP commit 3c28a13 There is a chance that we may want to revert this change in future. Previous commit message: This relaxes some validation logic newly introduced in the version of OkHttp used in N. This change leaves the character code validation stricter than it was in M by still preventing control codes like \n, \r, backspace and delete. It does allow developers to pass Java characters > 7F to addRequestProperty() and also receive headers from servers which contain characters > 7F. Android's HttpURLConnection does not follow the HTTP spec as it encodes request header values and interprets response headers as UTF-8 and not ISO-8859-1. If a server is expecting or sending ISO-8859-1 encoded characters >7F in headers then these will still be corrupted or misinterpreted by Android. However, this has been the behavior since L and is not changed here. The OkHttp change which caused characters >7F to generate an IllegalArgumentException and partially reverted here: square/okhttp#1785 See also: square/okhttp#1998 square/okhttp#2016 for recent upstream bugs. Bug: 28867041 Bug: https://code.google.com/p/android/issues/detail?id=210205 (cherry picked from commit 75687ca5ae54f417afb4c02ba04767da6786d829) Change-Id: Id683ec13142f1d7d8792143066f1dd2e5f62cf86
cm-gerrit
pushed a commit
to CyanogenMod/android_external_okhttp
that referenced
this pull request
Aug 24, 2016
This relaxes some validation logic newly introduced in the version of OkHttp used in N. This change leaves the character code validation stricter than it was in M by still preventing control codes like \n, \r, backspace and delete. It does allow developers to pass Java characters > 7F to addRequestProperty() and also receive headers from servers which contain characters > 7F. Android's HttpURLConnection does not follow the HTTP spec as it encodes request header values and interprets response headers as UTF-8 and not ISO-8859-1. If a server is expecting or sending ISO-8859-1 encoded characters >7F in headers then these will still be corrupted or misinterpreted by Android. However, this has been the behavior since L and is not changed here. The OkHttp change which caused characters >7F to generate an IllegalArgumentException and partially reverted here: square/okhttp#1785 See also: square/okhttp#1998 square/okhttp#2016 for recent upstream bugs. Bug: 28867041 Bug: https://code.google.com/p/android/issues/detail?id=210205 Change-Id: Ibdf14d819411a12fcc78d012bfca97db048b7e6e
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.
This includes potential security problems (newline characters) as well as
simple non-ASCII characters including international characters and emoji.
Closes #891