-
-
Notifications
You must be signed in to change notification settings - Fork 924
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
feat: Provide a way to set raw cookie headers #1414
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1414 +/- ##
======================================
Coverage 100% 100%
======================================
Files 38 38
Lines 2543 2562 +19
Branches 394 400 +6
======================================
+ Hits 2543 2562 +19
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #1414 +/- ##
======================================
Coverage 100% 100%
======================================
Files 39 39
Lines 2558 2579 +21
Branches 395 402 +7
======================================
+ Hits 2558 2579 +21
Continue to review full report at Codecov.
|
falcon/response.py
Outdated
if name == 'set-cookie': | ||
raise HeaderNotSupported('This method can not be used to remove cookies') | ||
|
||
# NOTE(kgriffs): normalize name by lowercasing it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this inline comment needed? We are not really doing the lowercasing in the line below the note?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Oops, that was some cruft leftover from refactoring.
Returns: | ||
str: The value of the specified header if set, or | ||
the default value if not set. | ||
""" | ||
return self._headers.get(name.lower(), default) | ||
|
||
name = name.lower() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...the normalization note could probably be plopped atop this instead (see the other comment deeper in this review), not a requirement from me though.
falcon/response.py
Outdated
items += self._extra_headers | ||
|
||
# NOTE(kgriffs): It is important to append these after self._extra_headers | ||
# in case the latter containes Set-Cookie headers that should be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
spelling containes (sic) ➡️ contains
falcon/response.py
Outdated
name = name.lower() | ||
|
||
if name == 'set-cookie': | ||
raise HeaderNotSupported('This method can not be used to set cookies') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a mistake per se, but if I were a native speaker I would probably dare to point out that cannot was a much more usual spelling variant (unless not formed part of another construction, or you wanted to sound emphatic). However, it seems you prefer can not by choice, and I am not very opinionated on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I guess I'm a bit old-school sometimes when it comes grammar. I don't mind substituting "cannot" here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, absolutely no need if this was your choice. Throughout the codebase, you consistently use can not, and @jmvrbanac writes cannot 🙂
Looks great, I had just a couple of minor nitpicks 👍 The only real code-related question could be, given Falcon's bare metal nature, whether this change grants an extra attribute on Response. But I don't see a clean solution that could do without it either. |
My thought was to try to minimize the changes at this point. I do think we could make the overall interface a bit friendlier when it comes to cookies. Maybe this is something we could look at for 3.1? |
(Feedback addressed) |
An extra attribute in the constructor adds about 40ns, which should be negligible? I am fine with this. |
While 40ns is not much, let me take a quick stab at reducing that a little bit, if nothing else by lazily creating the list object. |
dbd4ff4
to
5c35b3c
Compare
Looking good now! |
5c35b3c
to
a1944e2
Compare
5bd84a7
to
03d7835
Compare
Previously, setting raw cookies was not supported without having to subclass Response and override several methods. This patch adds official support for this functionality, while also explicitly disallowing the use of Set-Cookie with certain generic header manipulation methods that have semantics that are incompatible with Set-Cookie. BREAKING CHANGE: Previously, several methods in the Response class could be used to attempt to set raw cookie headers. However, due to the Set-Cookie header values not being combinable as a comma-delimited list, this resulted in an unexpected and/or incorrect response being constructed for the user agent in the case that more than one cookie was being set. Fixes falconry#1265
03d7835
to
45d7723
Compare
I forgot to update cookies.rst (now fixed). I also rebased on master and resolved the conflict. |
Previously, setting raw cookies was not supported without having to subclass Response and override several methods. This patch adds official support for this functionality, while also explicitly disallowing the use of Set-Cookie with certain generic header manipulation methods that have semantics that are incompatible with Set-Cookie.
Fixes #1265