-
-
reviewboard/notifications/webhooks.py (Diff revision 1) Col: 17 E131 continuation line unaligned for hanging indent
-
reviewboard/notifications/webhooks.py (Diff revision 1) Col: 80 E501 line too long (90 > 79 characters)
-
reviewboard/notifications/webhooks.py (Diff revision 1) Col: 80 E501 line too long (82 > 79 characters)
Fix dispatching of webhooks with non-ASCII content by sending only binary strings
Review Request #8560 — Created Dec. 4, 2016 and submitted
When dispatching a webhook that contained non-ASCII content, the urlopen call raised an exception
that reported an encoding error, complaining that some characters are not encodable with theascii
encoding.This issue occurs because the
urlopen
implementation concatenates the given URL, headers, and body
using string concatenation, and, if the resulting string is a unicode string, encodes it implicitly
as ASCII before sending it to the server.This change encodes all data passed to
urlopen
as binary strings, so that the result of string
concatenation is also a binary string, thus necessitating no implicit encoding. While writing tests
for this issue, an issue with silently swallowed assertions in the test_urlopen
was fixed.
Added 4 unit tests for non-ASCII custom, JSON, XML and Form-Data content.
Checked locally that payloads are sent without issue.
Added check that all data sent to_test_dispatch
is made of binary strings.
Description | From | Last Updated |
---|---|---|
Col: 17 E131 continuation line unaligned for hanging indent |
reviewbot | |
Col: 80 E501 line too long (90 > 79 characters) |
reviewbot | |
Col: 80 E501 line too long (82 > 79 characters) |
reviewbot | |
Can we switch these lines (to keep it in alphabetical order)? |
david | |
I know the other methods in here have "Test ..." but our general convention for unit test docstrings is "Testing … |
david | |
Same here. |
david | |
Same here. |
david | |
Same here. |
david | |
Please add a blank line between these two. |
david | |
Please add a blank line between these two. |
david | |
Should have two blank lines between top-level classes. |
david | |
We should get six from django.utils, rather than the standalone package. |
david | |
Please add a blank line between these two. |
david | |
This kind of comment (narrating the code) doesn't really help too much with understanding the code. The call to .encode() … |
david | |
Again, this comment is kind of narrative instead of explanatory. Perhaps an even better solution than doing this test would … |
david | |
Instead of having this comment, can we have a unit test that calls this while spying on urlopen/Request and verifies … |
david | |
Again, this comment doesn't really add to the understanding of the code. |
david | |
'six' imported but unused |
reviewbot |
Change Summary:
Fix line length issues from ReviewBot
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 2 (+106 -7) |
-
Tool: Pyflakes Processed Files: reviewboard/notifications/webhooks.py reviewboard/notifications/tests.py Tool: PEP8 Style Checker Processed Files: reviewboard/notifications/webhooks.py reviewboard/notifications/tests.py
-
-
reviewboard/notifications/tests.py (Diff revision 2) Can we switch these lines (to keep it in alphabetical order)?
-
reviewboard/notifications/tests.py (Diff revision 2) I know the other methods in here have "Test ..." but our general convention for unit test docstrings is "Testing ..."
-
-
-
-
-
-
reviewboard/notifications/tests.py (Diff revision 2) Should have two blank lines between top-level classes.
-
reviewboard/notifications/webhooks.py (Diff revision 2) We should get
six
fromdjango.utils
, rather than the standalone package. -
Change Summary:
Fix import and formatting issues from David Trowbridge's review
Description: |
|
|||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Commit: |
|
|||||||||||||||
Diff: |
Revision 3 (+110 -7) |
-
Tool: Pyflakes Processed Files: reviewboard/notifications/webhooks.py reviewboard/notifications/tests.py Tool: PEP8 Style Checker Processed Files: reviewboard/notifications/webhooks.py reviewboard/notifications/tests.py
-
-
reviewboard/notifications/webhooks.py (Diff revision 3) This kind of comment (narrating the code) doesn't really help too much with understanding the code. The call to
.encode()
is pretty self-explanatory. -
reviewboard/notifications/webhooks.py (Diff revision 3) Again, this comment is kind of narrative instead of explanatory. Perhaps an even better solution than doing this test would be to put
bytes = bytes.encode('utf-8')
into each of the cases above where it's needed. -
reviewboard/notifications/webhooks.py (Diff revision 3) Instead of having this comment, can we have a unit test that calls this while spying on
urlopen
/Request
and verifies that all headers are bytes? That way we won't accidentally regress this. -
reviewboard/notifications/webhooks.py (Diff revision 3) Again, this comment doesn't really add to the understanding of the code.
Change Summary:
Remove added comments and move
encode('utf-8')
calls inwebhooks.py
Description: |
|
|||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Commit: |
|
|||||||||||||||||||||
Diff: |
Revision 4 (+100 -7) |
-
Tool: Pyflakes Processed Files: reviewboard/notifications/webhooks.py reviewboard/notifications/tests.py Tool: PEP8 Style Checker Processed Files: reviewboard/notifications/webhooks.py reviewboard/notifications/tests.py
-
Change Summary:
Remove unnecessary import of
six
.
Description: |
|
||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Commit: |
|
||||||||||||||||||||||||
Diff: |
Revision 5 (+99 -7) |
-
Tool: Pyflakes Processed Files: reviewboard/notifications/webhooks.py reviewboard/notifications/tests.py Tool: PEP8 Style Checker Processed Files: reviewboard/notifications/webhooks.py reviewboard/notifications/tests.py
-
We have a specific format we like for the review request descriptions, which are used for the commit message. We like to clearly communicate what the problem was before and how it was fixed. Would you mind updating the review request for that? We have details and examples up at https://www.notion.so/reviewboard/Writing-Good-Change-Descriptions-10529e7c207743fa8ca90153d4b21fea
Summary: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description: |
|