-
Notifications
You must be signed in to change notification settings - Fork 7.8k
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
Issue 23955: setcookie() to send Max-Age attribute #238
Conversation
Signed-off-by: Andrey Andreev <narf@bofh.bg>
Reading the specs, both expires and max-age are optional: If a cookie has both the Max-Age and the Expires attribute, the Max- Also, max-age can be negative. I'd rather add a new arg to setcookie and let it up to user which combination of attributes he want's to send. That needs probably a small RFC and discussion. Also - that attributes are case sensitive. And even though - a test is always needed :) |
Yes, this definitely needs an RFC. Besides that, it’s a good idea. |
Fixed the negative values - good point! However, while adding another parameter to allow the user a choice of attributes would need an RFC, I don't see why this one would require that. The goal is to solve a problem, not just allow the user to solve it. And yes - the attributes should be implemented in a case-sensitive way, that's why I've changed them. All of the RFCs that I read (the one linked in the PR description and those mentioned in the linked PHP bug IDs) mention them with an upper-case letter for each word in the attribute name. Otherwise feel free to suggest any improvements on my code. I'm no C programmer and I've only written a few patches through the years. This one just seemed easy to do. :) |
That's for instance what stands in the linked document. If the attribute-name case-insensitively matches the string The C coding looks fine so far, though i haven't tested yet. The point about how to implement that is exactly what an RFC should solve. I get your idea not to complicate it now :) . Please look here for which RFCs already exist https://wiki.php.net/rfc . Once the RFC is there, give a note on the internals list. There will be sure more questions and improvements. Also the tests are still a must :) |
So they say that the comparison is made in a case-insensitive manner (I'm assuming that, as nothing is mentioned about case-sensitive matches at all) - representing the attributes as they are specified in the RFC still doesn't hurt. I'm not getting what the argument here is all about - just trying to be consistent with the RFC. :) I've read some of the RFCs at wiki.php.net, haven't used internals though. I have to post on both, you say? I'll see what I can do about those tests. :) |
Of course that capitals don't hurt, there was just not need for that and the patch would be cleaner. First write an RFC (you'll need a wiki account probably), then expose it on internals. Everything happens for the first time somewhen :) |
My original code produced segmentation faults, now it works, with tests for |
If only I had permissions to create pages on the wiki ... |
That’s actually a turing test for people writing RFC. Can you find out how to get a Wiki account? :) |
I have one, the problem is that all pages are read-only and when I try to access a non-existent page it shows a suggestion that I can create it by clicking on a "Create this page" button, but no such button is shown anywhere. |
When PHP 5.5.0 be officially stable released? |
I wrote about this on internals a week ago, btw: http://marc.info/?l=php-internals&m=135514355208843 Since the wiki appears to be read-only (again, I have an account), do I have to do anything else than just wait for it to gain attention? @asifsaif90 This isn't the right place to ask, but they're still discussing the release schedule, so I don't think that anybody could answer you anyway. |
Have you read the notes on the wiki registration page? There are some more steps needed to become write access. |
Oh, right ... thanks @weltling. |
Updated the description with a link to the RFC. |
@@ -1201,6 +1202,11 @@ static void php_session_send_cookie(TSRMLS_D) /* {{{ */ | |||
smart_str_appends(&ncookie, COOKIE_EXPIRES); | |||
smart_str_appends(&ncookie, date_fmt); | |||
efree(date_fmt); | |||
|
|||
char maxage[12]; | |||
sprintf(maxage, "%li", PS(cookie_lifetime)); |
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.
Please use snprintf or spprintf, never sprintf. Also, in this case probably smart_str_append_long would be appropriate.
OK, hopefully it's all good to go now. |
looks ok now |
Great, I guess I'll be just waiting for it to get merged then. :) |
@smalyshev will you merge or should I? |
Comment on behalf of lstrojny at php.net: Merged in 5.5 and master. Thanks for your contribution! |
I am sorry to say that, but his commit caused me some troubles. Please, add some way to determine the time stamp of the max-age of the cookie, some way to disable its output completely, or any pretty solution to this matter. |
Tests ARE included in the patch and they are in pure PHP, predicting the value is easy. |
Deleting it is much easier! In other way to explain, I set the time stamp of the request for both sites to be equal value, so all dates and functions will use that stamp for both sites. Previously, the cookie got its value only from the stamp I provide. Now, the max-age value is determined by subtracting the actual value (not the one I set and I found no way to control it) of now() time stamp from the time stamp I provide for expiration. |
setcookie()
should send not only the Expires, but also the Max-Age attribute.Changed the session extension to send the Max-Age attribute as well.
As described in #23955, a user agent having an erroneously configured timezone would have issues when calculating when to expire the cookie.
As described in RFC6265, Max-Age must be implemented by user agents in the following manner:
Given those characteristics, it only makes sense that both Expires and Max-Age are sent together.
This MIGHT also fix #43439, but I'm not really sure about it - should be checked.
Edit:
https://wiki.php.net/rfc/cookie_max-age