Skip to content
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

Merged
merged 3 commits into from
Feb 14, 2019

Conversation

kgriffs
Copy link
Member

@kgriffs kgriffs commented Jan 18, 2019

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

@codecov
Copy link

codecov bot commented Jan 18, 2019

Codecov Report

Merging #1414 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff           @@
##           master   #1414   +/-   ##
======================================
  Coverage     100%    100%           
======================================
  Files          38      38           
  Lines        2543    2562   +19     
  Branches      394     400    +6     
======================================
+ Hits         2543    2562   +19
Impacted Files Coverage Δ
falcon/response.py 100% <100%> (ø) ⬆️
falcon/errors.py 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e5dd5ea...5b97a04. Read the comment docs.

@codecov
Copy link

codecov bot commented Jan 18, 2019

Codecov Report

Merging #1414 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff           @@
##           master   #1414   +/-   ##
======================================
  Coverage     100%    100%           
======================================
  Files          39      39           
  Lines        2558    2579   +21     
  Branches      395     402    +7     
======================================
+ Hits         2558    2579   +21
Impacted Files Coverage Δ
falcon/response.py 100% <100%> (ø) ⬆️
falcon/errors.py 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 793f304...4632bb0. Read the comment docs.

if name == 'set-cookie':
raise HeaderNotSupported('This method can not be used to remove cookies')

# NOTE(kgriffs): normalize name by lowercasing it
Copy link
Member

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?

Copy link
Member Author

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()
Copy link
Member

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.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling containes (sic) ➡️ contains

name = name.lower()

if name == 'set-cookie':
raise HeaderNotSupported('This method can not be used to set cookies')
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

@vytas7 vytas7 Jan 19, 2019

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 🙂

@vytas7
Copy link
Member

vytas7 commented Jan 19, 2019

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.

@kgriffs
Copy link
Member Author

kgriffs commented Jan 19, 2019

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?

@kgriffs
Copy link
Member Author

kgriffs commented Jan 19, 2019

(Feedback addressed)

@vytas7
Copy link
Member

vytas7 commented Jan 19, 2019

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?

An extra attribute in the constructor adds about 40ns, which should be negligible? I am fine with this.

vytas7
vytas7 previously approved these changes Jan 19, 2019
@kgriffs kgriffs requested a review from nZac January 22, 2019 21:56
@kgriffs
Copy link
Member Author

kgriffs commented Jan 29, 2019

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?

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.

vytas7
vytas7 previously approved these changes Feb 2, 2019
@vytas7
Copy link
Member

vytas7 commented Feb 2, 2019

Looking good now!

vytas7
vytas7 previously approved these changes Feb 9, 2019
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
@kgriffs
Copy link
Member Author

kgriffs commented Feb 13, 2019

I forgot to update cookies.rst (now fixed). I also rebased on master and resolved the conflict.

@vytas7 vytas7 merged commit 75824ba into falconry:master Feb 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants