CP-50079: Parse cookies correctly #5821
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
psafont
reviewed
Jul 12, 2024
|
Passed BST+BVT (Run 201239) |
contificate
reviewed
Jul 15, 2024
last-genius
force-pushed
the
private/asultanov/cookies-handling
branch
from
f995928
to
16a5a35
Compare
psafont
approved these changes
Jul 15, 2024
contificate
approved these changes
Jul 15, 2024
lindig
reviewed
Jul 15, 2024
| (* Determine if ';' or '&' is used as the separator. | ||
| Both are assumed to be illegal characters otherwise *) | ||
| let sep = | ||
| match Astring.String.find (fun c -> c = ';') xs with |
There was a problem hiding this comment.
This means we don't support a mix of ; and &. You could have used Astring.String.fields ~is_sep:(fun c -> c = ';' || c = '&')
There was a problem hiding this comment.
Is this a reasonable use case? Could do it if people think it's something worth supporting.
There was a problem hiding this comment.
I would think this is a bit weird but it's a simple solution because you don't have to detect the delimiter but rather accept both. Later we we restrict this by accepting only one and failing we we detect the other.
last-genius
force-pushed
the
private/asultanov/cookies-handling
branch
from
16a5a35
to
b3f4b91
Compare
|
Got rid of |
lindig
reviewed
Jul 16, 2024
lindig
approved these changes
Jul 16, 2024
The suites are ordered and some take quite a long time to run, so introduce an option to only run some of them if necessary. Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com>
We used to send and parse cookies (internally, therefore it wasn't a big problem) with '&' as separators. Now we also accept ';' as separators (RFC-compliant), as preparation for sending cookies with ';' in the future. Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com>
Test helper functions had to be reworked to also allow sending HTTP requests through normal sockets, not only file sockets. A test was moved from the legacy endpoint to the new one. Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com>
Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com>
Signed-off-by: Andrii Sultanov <andrii.sultanov@cloud.com>
last-genius
force-pushed
the
private/asultanov/cookies-handling
branch
from
41c66fa
to
45cdd70
Compare
|
Squashed the fixes. Ready for merging. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Best reviewed by commit.
Currently we send and parse cookies incorrectly (internally, therefore it wasn't a big problem) with
&as separators. This PR also accepts;as separators (to be RFC-compliant), in preparation for sending cookies with;in the future. Currently this change is limited to servers (accepting cookies), as old servers could interact with new clients sending newly-formatted cookies during upgrades, thus breaking them. We should wait until all servers we support upgrades from are new and then update the clients too. (We should really get a centralised place to track such long-term deprecation-like things.)Removes legacy
sync_config_filesinterface - please advise as to what's the best way to proceed here is. Should we warn that said endpoint is deprecated, only support/2(what my PR does at the moment)? Should we respond with new data to legacy requests instead?Expanded quicktests to verify correct parsing of cookies. Had to add new helper functions since
sync_config_filesrequests from unix file sockets are always authenticated - we need to send a real one to check.Qt.httpis not a good fit here since it eventually calls into our library which always sets thebody = None, and we need to verify the body itself.Also adds
-run-only X,Y,Zand-list-testsparameters to quicktests (currently they are not 'quick' at all).== These changes passed the quicktests, currently also running full BST+BVT.