Align cookie sorting with RFC6265 #2524
Conversation
|
I'm not entirely sure why this is, but I think I might've opted to leave that out and instead sort on names because... Since we don't store creation time in the cookie file, reading back the cookies risk getting them in a different order / time and then sort them differently which is undesired. Any thoughts on how to handle that? |
|
On 23 Apr 2018, at 23:15, Daniel Stenberg ***@***.***> wrote:
I'm not entirely sure why this is, but I think I might've opted to leave that out and instead sort on names because...
Since we don't store creation time in the cookie file, reading back the cookies risk getting them in a different order / time and then sort them differently which is undesired. Any thoughts on how to handle that?
I was thinking about that as well. I think the only solution would be to store creation time in the cookie file as well (and treat a missing creation time either as a special "cookie-epoch” to allow for deterministic sorting when loading a file without creation times). This does however penalize loading/parsing for large cookie files so it might not be worth it.
|
|
Here's a thought: If the creation time is only used for sorting, then the exact time isn't important but only the relative time. Then as long as the cookies are saved to file in creation-order, they can be loaded back in that order and get an artificial time just cookie-epoch and an increasing number for each loaded cookie. As long as the last loaded cookie's time ends up earlier than the first possible "live" cookie... But then perhaps we could use a simple counter for the live ones as well!? |
|
On 24 Apr 2018, at 00:21, Daniel Stenberg ***@***.***> wrote:
Here's a thought:
If the creation time is only used for sorting, then the exact time isn't important but only the relative time. Then as long as the cookies are saved to file in creation-order, they can be loaded back in that order and get an artificial time just cookie-epoch and an increasing number for each loaded cookie. As long as the last loaded cookie's time ends up earlier than the first possible "live" cookie... But then perhaps we could use a simple counter for the live ones as well!?
I like that idea. AFAICT from the RFC, creation-time is only used as a tie-breaker in sorting so you are right that we can avoid storing the exact time by using an artificial epoch based relative time. I’ll try that out to see what it would look like.
|
|
Thinking more about this, we run into a problem with this scheme if there are multiple cookie files via |
|
Right, and there's a potential problem when we read a file that is created by someone/something else as we then assume the order of the cookies means something that the creator maybe didn't intend. But on the other hand, the cookie order is not controlled by those users even without this change. I think this simplified creation-date logic can still work, even if it doesn't work cross-files on load. I think that's a minor issue we can still live with. Can you think of any major downside that isn't basically present already? |
|
On 26 Apr 2018, at 23:30, Daniel Stenberg ***@***.***> wrote:
Right, and there's a potential problem when we read a file that is created by someone/something else as we then assume the order of the cookies means something that the creator maybe didn't intend. But on the other hand, the cookie order is not controlled by those users even without this change.
If anything, this would give them the power to control the ordering should they want to (but that depends on how/if this is explicitly documented).
I think this simplified creation-date logic can still work, even if it doesn't work cross-files on load. I think that's a minor issue we can still live with.
For single-file loads it will do the right thing, and that’s probably not a small percentage of use cases. For multi-file, it won’t be further away from the RFC order wrt what we have today.
Can you think of any major downside that isn't basically present already?
Thinking more about this, I can’t see anything that I would qualify as major. That being said, the question is if the added code complication gives enough benefit to be worth it? I obviously think aligning closer with the RFC is a Good Thing, but it’s at the same time a fairly gain for the user (if one at all).
|
danielgustafsson
force-pushed
the
dg-cookie_creation_time
branch
from
301d7c6
to
332a4e5
Compare
|
Pushed a rebased version which implements the sort-order creation-time scheme. |
|
Coming back to this @danielgustafsson. Do you still think this is a good addition? If so, can you please fix the conflict and rebase this on top of the latest master and we can work on getting this merged, at least in the next feature window. |
danielgustafsson
force-pushed
the
dg-cookie_creation_time
branch
from
332a4e5
to
ac5f729
Compare
|
On 24 Aug 2018, at 09:58, Daniel Stenberg ***@***.***> wrote:
Coming back to this @danielgustafsson. Do you still think this is a good addition? If so, can you please fix the conflict and rebase this on top of the latest master and we can work on getting this merged, at least in the next feature window.
I still think this is good, as it will make it more deterministic backed by an RFC. I’ve pushed a rebase which tests all green locally.
|
danielgustafsson
force-pushed
the
dg-cookie_creation_time
branch
2 times, most recently
from
b1d3b17
to
3ee2369
Compare
According to RFC6265 section 5.4, cookies with equal path lengths SHOULD be sorted by creation-time (earlier first). This adds a creation-time record to the cookie struct in order to make cookie sorting more deterministic. The creation-time is defined as the order of the cookies in the jar, the first cookie read fro the jar being the oldest. The creation-time is thus not serialized into the jar. Also remove the strcmp() matching in the sorting as there is no lexicographic ordering in RFC6265. Existing tests are updated to match.
danielgustafsson
force-pushed
the
dg-cookie_creation_time
branch
from
3ee2369
to
a68ee3a
Compare
danielgustafsson
force-pushed
the
dg-cookie_creation_time
branch
from
a68ee3a
to
f93cff3
Compare
|
This now builds green after fixing a silly test failure, I also found and added another typo. Should be ready for review now. |
|
Awesome work @danielgustafsson! Thanks a lot. |
|
Excited to see this go in, thanks for reviewing! |
According to RFC6265 section 5.4, cookies with equal path lengths SHOULD be sorted by creation-time (earlier first). This adds a creation-time record to the cookie struct in order to make cookie sorting more deterministic. The creation-time is defined as the order of the cookies in the jar, the first cookie read fro the jar being the oldest. The creation-time is thus not serialized into the jar. Also remove the strcmp() matching in the sorting as there is no lexicographic ordering in RFC6265. Existing tests are updated to match. Closes curl#2524
While reading code I realised that the cookie sort order isn't really complying withRFC6265. This may be intentional, but I figured I'd hack up a patch as a proposal to improve on that as sort of a "does this make sense" question. According to RFC6265 section 5.4, cookies with equal path lengths SHOULD be sorted by creation-time (earlier first). This adds a creation-time record to the cookie struct in order to make cookie sorting more deterministic. Also remove the
strcmp()matching in the sorting as there is no lexicographic ordering in RFC6265. Existing tests are updated to match.Also includes a commit with a few typo fixes.