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

Attention: Patch coverage is 97.78813% with 19 lines in your changes missing coverage. Please review.

Project coverage is 98.24%. Comparing base (43e3041) to head (40622b3).
Report is 209 commits behind head on v3.0.

Files with missing lines	Patch %	Lines
litestar/middleware/cors.py	0.00%	8 Missing ⚠️
litestar/_signature/model.py	75.00%	1 Missing and 2 partials ⚠️
...estar/handlers/websocket_handlers/route_handler.py	90.90%	1 Missing and 2 partials ⚠️
litestar/_asgi/routing_trie/traversal.py	80.00%	0 Missing and 1 partial ⚠️
litestar/exceptions/responses/__init__.py	97.72%	1 Missing ⚠️
litestar/logging/config.py	98.03%	0 Missing and 1 partial ⚠️
litestar/static_files.py	98.63%	0 Missing and 1 partial ⚠️
litestar/testing/transport.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             v3.0    #3034      +/-   ##
==========================================
- Coverage   98.26%   98.24%   -0.03%     
==========================================
  Files         322      323       +1     
  Lines       14733    14504     -229     
  Branches     2343     2299      -44     
==========================================
- Hits        14477    14249     -228     
- Misses        117      118       +1     
+ Partials      139      137       -2     

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

[JacobCoffee]

@floxay @provinzkraut can we merge this now

[JacobCoffee]

v3 branch is available with changes so this could be merged into that if ci passes

[github-actions]

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