Bump cookie and express in /example/e2e

[dependabot]

Bumps cookie and express. These dependencies needed to be updated together.
Updates cookie from 0.6.0 to 0.7.1

Release notes

Sourced from cookie's releases.

0.7.1

Fixed

• Allow leading dot for domain (#174)
  • Although not permitted in the spec, some users expect this to work and user agents ignore the leading dot according to spec
• Add fast path for serialize without options, use obj.hasOwnProperty when parsing (#172)

jshttp/cookie@v0.7.0...v0.7.1

0.7.0

• perf: parse cookies ~10% faster (#144 by @​kurtextrem and #170)
• fix: narrow the validation of cookies to match RFC6265 (#167 by @​bewinsnw)
• fix: add main to package.json for rspack (#166 by @​proudparrot2)

jshttp/cookie@v0.6.0...v0.7.0

Commits

• cf4658f 0.7.1
• 6a8b8f5 Allow leading dot for domain (#174)
• 58015c0 Remove more code and perf wins (#172)
• ab057d6 0.7.0
• 5f02ca8 Migrate history to GitHub releases
• a5d591c Migrate history to GitHub releases
• 51968f9 Skip isNaN
• 9e7ca51 perf(parse): cache length, return early (#144)
• d6f39b0 Fix tests for old node
• 6bb701f Remove failing scorecard
• Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by blakeembrey, a new releaser for cookie since your current version.

Updates express from 4.21.0 to 4.21.1

Release notes

Sourced from express's releases.

4.21.1

What's Changed

• Backport a fix for CVE-2024-47764 to the 4.x branch by @​joshbuker in expressjs/express#6029
• Release: 4.21.1 by @​UlisesGascon in expressjs/express#6031

Full Changelog: expressjs/express@4.21.0...4.21.1

Changelog

Sourced from express's changelog.

4.21.1 / 2024-10-08

• Backported a fix for CVE-2024-47764

Commits

• 8e229f9 4.21.1
• a024c8a fix(deps): [email protected]
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[github-management-service]

It looks like you are reviewing a Dependabot upgrade PR! 🛠️
That’s great! Keeping our packages up to date to fix security issues in our stack is super important. Team Application Security wants to help make this process as easy and low friction as possible while still moving at pace.

We aim to merge Dependabot PRs within the below timeframes. The objectives are based on the severity of the security vulnerability we are mitigating with the upgrade:

Severity	Target Merge (days)
CRITICAL	7 days
HIGH	14 days
MEDIUM	30 days
LOW	90 days

🎯 Target merge date for this PR: 17/01/2025 🎯

FAQ

What if we aren’t vulnerable to this particular CVE? Do we still have to upgrade the package?

It’s still a good idea to upgrade the package if we can. With new code patterns and paths being introduced every day, we have no guarantee that we won’t later make ourselves vulnerable. Keeping packages up to date as a matter of due course is also good hygiene.

What if we’re not vulnerable and upgrading is going to be a lot of work?

In these cases it’s a good idea to list out the steps you took to confirm we are not vulnerable in this PR. The PR can then be closed and the corresponding Dependabot Alert should be dismissed with the triage steps included as a comment. Please get in touch with Team Application Security via #ask-security before dismissing any CRITICAL alerts.

This is a major version upgrade that requires substantial code refactoring. What should I do?

If the upgrade requires substantial refactoring then it is possible that we will miss the objectives we have outlined above. In these cases, you should add the dependabot-refactor-required label to this PR and ping #ask-security for further advice.

[elizabit-b]

Checked with Dale who sees no breaking changes 👍