fix!: cookie string parser

[floxay]

Fixes #3023

[provinzkraut]

I think this should be

Suggested change

	cookies = [cookie.split("=", 1) if "=" in cookie else (cookie, cookie) for cookie in cookie_string.split(";")]
	cookies = [cookie.split("=", 1) if "=" in cookie else (cookie, "") for cookie in cookie_string.split(";")]

I've checked out other implementations and found that:

• Stdlib refuses to parse this
• Wekzeug defaults to the cookie name and an empty value
• Starlette behaves the same we do

In addition, Starlette also specifically references this: https://bugzilla.mozilla.org/show_bug.cgi?id=169091.

Personally, I think defaulting to an empty value makes more sense than defaulting to the name as a value, as that's rather arbitrary.

[floxay]

I agree that an empty string makes way more sense as a value.

The only reason I have went with (cookie, cookie) was to not change the output of the data extractors in a way that would potentially break user code (or log DB queries, etc.) in case someone is currently looking for these optional attributes among the cookie values.

[provinzkraut]

Yeah, I think this is something we'd either have to hide behind a feature flag or wait for 3.0 to release due to the breaking nature.

[floxay]

Unsure how a feature flag for this would work, my initial idea was to use "experimental features" but the extractor has no access to the app.
Adding an additional parameter such as future_cookie_string_parsing: bool = False to ResponseDataExtractor to control the behavior of parse_cookie_string seems to be the easiest solution. (but would be slightly problematic when it disappears in 3.0)
However after I added this future_cookie_string_parsing parameter I noticed another issue; #3040, due to this one I think it might be better to just wait until 3.0 with both of them, if so, should the target branch be changed?

[provinzkraut]

I think it might be better to just wait until 3.0 with both of them

Yes, I agree.

if so, should the target branch be changed?

You can leave them as-is for now. We'll update the branch once the 3.0 work officially has been started.

[peterschutt]

PR is pointed at v3.0 branch now, can we merge it there?

[JacobCoffee]

lgtm except for mentioned comments above; if we want to hold these until 3.0 i think pointing it at develop for now might make sense?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.26%. Comparing base (43e3041) to head (f6c8bdb).
Report is 16 commits behind head on v3.0.

Additional details and impacted files

@@           Coverage Diff           @@
##             v3.0    #3034   +/-   ##
=======================================
  Coverage   98.26%   98.26%           
=======================================
  Files         322      322           
  Lines       14733    14733           
  Branches     2343     2343           
=======================================
  Hits        14477    14477           
  Misses        117      117           
  Partials      139      139           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JacobCoffee]

@floxay @provinzkraut can we merge this now

[github-actions]

Documentation preview will be available shortly at https://litestar-org.github.io/litestar-docs-preview/3034