Skip to content

Proper handling of max-age and expires for cookies#7925

Closed
watzon wants to merge 9 commits intocrystal-lang:masterfrom
watzon:patch/cookie-expiration
Closed

Proper handling of max-age and expires for cookies#7925
watzon wants to merge 9 commits intocrystal-lang:masterfrom
watzon:patch/cookie-expiration

Conversation

@watzon
Copy link
Contributor

@watzon watzon commented Jun 26, 2019

This PR is based off of #5042. Seeing as it has been sitting there for some time with no movement, and the current Cookie parsing is breaking with large max-age values, I decided to get to ball rolling again.

@bcardiff bcardiff requested a review from straight-shoota June 26, 2019 12:51
@watzon
Copy link
Contributor Author

watzon commented Jul 2, 2019

It looks like the failures are due to a memory leak of some kind, any idea what could be causing it?

@asterite
Copy link
Member

asterite commented Jul 2, 2019

I think compiler specs are leaking. I just noticed that codegen specs that don't use the prelude are allocating memory using Pointer.malloc or Foo.new which end up calling LibC.mallocand that memory is never freed.

However, specs usually don't allocate that much memory in tests so maybe there's something else going on... but it's hard to debug. Plus it only happens on linux 32, mostly.

@watzon
Copy link
Contributor Author

watzon commented Jul 2, 2019

It's weird. I can't even run the full library specs on my machine or it eats up all my RAM. I've had to force shutdown my laptop twice. The cookie specs themselves pass though.

Copy link
Member

@asterite asterite left a comment

Choose a reason for hiding this comment

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

Looks good!

However, the time comparisons seem a bit fragile, for example if there's a hiccup in CI or something. I think we should bring timecop into the standard library to be able to properly test these things. But we can do it later.

Co-Authored-By: Blacksmoke16 <yomoejoe@gmail.com>
@watzon
Copy link
Contributor Author

watzon commented Jul 17, 2019

Holy moley, the specs actually passed

@watzon
Copy link
Contributor Author

watzon commented Jul 19, 2019

Looks like we just need to get @straight-shoota in here for review

@Sija
Copy link
Contributor

Sija commented Jul 19, 2019

@watzon Two approvals is what's needed (would gr8 to have @straight-shoota review nevertheless).

@RX14
Copy link
Member

RX14 commented Jul 24, 2019

I'd like another approval of the changes made. There's only been one review since the last commit.

@straight-shoota straight-shoota added kind:bug A bug in the code. Does not apply to documentation, specs, etc. pr:needs-work A PR requires modifications by the author. topic:stdlib:networking labels Feb 9, 2020
@ghost
Copy link

ghost commented Sep 27, 2020

Does this PR need someone to adopt it? I could really use the change.

@watzon
Copy link
Contributor Author

watzon commented Sep 27, 2020

@yui-knk I believe so. I just don't have time to work on the requested changes right now.

@straight-shoota straight-shoota removed the pr:needs-work A PR requires modifications by the author. label Dec 8, 2020
@beta-ziliani
Copy link
Member

Closing this one now that we have #10564 to focus on. Thanks for the effort @watzon !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind:bug A bug in the code. Does not apply to documentation, specs, etc. topic:stdlib:networking

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants