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

Fixed set-cookie regex to allow whitespace #5408

Merged
merged 5 commits into from Jan 3, 2018
Merged

Fixed set-cookie regex to allow whitespace #5408

merged 5 commits into from Jan 3, 2018

Conversation

bararchy
Copy link
Contributor

Add an optional whitespace to set-cookie regex
This is a fix for: #5407

Add an optional whitespace to set-cookie regex
@@ -81,7 +81,7 @@ module HTTP
end

CookieString = /(?:^|; )#{Regex::CookiePair}/
SetCookieString = /^#{Regex::CookiePair}(?:; #{Regex::CookieAV})*$/
SetCookieString = /^#{Regex::CookiePair}(?:;\s?#{Regex::CookieAV})*$/
Copy link
Member

Choose a reason for hiding this comment

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

Can anybody check the RFC whether zero or more or zero or one are allowed? In the case of zero or more this should probably use something like {0,256} or so rather than ?

Copy link
Member

Choose a reason for hiding this comment

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

According to RFC 2965, white space is permitted between tokens. It is not explicit if it means "one" or "multiple" but I'd assume withour further specifictation it is to be understood as "any number".

Whitespaces are also allowed in other places, for example between attribute and = (this is explicitly mentioned in the RFC). Also the date formats like the one described by RFC 1123 actually allow arbitrary number of whitespace between the tokens.

So, there are several issues with this cookie string parser. This PR is probably good for a quick fix, but the entire parse will need to be refactored, probably using a custom parser instead of regular expressions.

Copy link
Contributor

Choose a reason for hiding this comment

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

So the regex addition should be changed to \s*.

Copy link
Member

@jhass jhass Dec 19, 2017

Choose a reason for hiding this comment

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

I would put a specific limit like I suggested above, * tends to be dangerous or at least slow when fed untrusted input.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

so \s{0,256} ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

I don't think it matters, really. If it was up to me, I'd choose \s* because it's simpler and the entire regex parser is not "safe" and needs an oberhaul anyway.

Copy link
Contributor

Choose a reason for hiding this comment

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

We enforce a 16KiB length limit on parsed HTTP headers, so we should be fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So... merge?

Copy link
Member

Choose a reason for hiding this comment

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

No, change to \s*

@bararchy
Copy link
Contributor Author

@straight-shoota Is this fine from your side now?

Copy link
Member

@jhass jhass left a comment

Choose a reason for hiding this comment

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

Sorry, really need a spec or two here.

@bararchy
Copy link
Contributor Author

I'll admit to not looking, but isn't this feature already covered with specs? Of it is, they pass, if not, then we didn't lose anything and I can add some specs anytime.
Right now this is a very small fix, "it works for me" though I know this is by no way enough, it is what I can offer at this time

@straight-shoota
Copy link
Member

Why don't you just add a simple spec to cookie_spec? The new behaviour is not covered right now, all specs assume exactly one space character after each separator. We need specs with zero whitespace and multiple differen whitespace characters.

Something like this should do:

cookie = parse_set_cookie("key=value; path=/test")
parse_set_cookie("key=value;path=/test").should eq cookie
parse_set_cookie("key=value;  \t\npath=/test").should eq cookie

@bararchy
Copy link
Contributor Author

@straight-shoota Will do, thanks

@bararchy
Copy link
Contributor Author

bararchy commented Jan 3, 2018

@straight-shoota @jhass @RX14 @asterite
Added specs, all ok for merge?

@asterite
Copy link
Member

asterite commented Jan 3, 2018

@bararchy you are missing a do after it

@bararchy
Copy link
Contributor Author

bararchy commented Jan 3, 2018

@asterite good catch, never edit on github :
Fixed.

@RX14
Copy link
Contributor

RX14 commented Jan 3, 2018

Needs a format.

@bararchy
Copy link
Contributor Author

bararchy commented Jan 3, 2018

@RX14 You mean run it with crystal format tool?

@bararchy
Copy link
Contributor Author

bararchy commented Jan 3, 2018

@RX14 Done.

@jhass jhass added this to the Next milestone Jan 3, 2018
@jhass jhass merged commit 2dcc1b9 into crystal-lang:master Jan 3, 2018
@jhass
Copy link
Member

jhass commented Jan 3, 2018

Thanks!

lukeasrodgers pushed a commit to lukeasrodgers/crystal that referenced this pull request Jan 7, 2018
* Fixed set-cookie regex to allow whitespace

Add an optional whitespace to set-cookie regex

* Changed \s? to \s* as per request

* added specs

* fixed missing do after it

* formatted
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants