Intended change
-
The Cookie constructor is changed from
Cookie([String name, String value])
to
Cookie(String name, String value)
-
The Cookie.name and Cookie.value setters now validate the name and values are valid according to RFC 6265 and cannot be null.
Rationale
The Cookie() constructor originally allowed a null name and value, however the Dart 1.3.0 release (2014) introduced a bug that meant the name and value parameters could not be null, because a NoSuchMethod exception would be thrown. Effectively the optional parameters became mandatory and the class could not be instantiated without passing two non-null Strings.
The name and string constructor parameters have been checked for RFC 6265 validity for a long time now. However the name and value setters were completely unchecked and allowed any string and even null, making it possible to construct an invalid cookie that the other side would reject. This is inconsistent with the strict checking in the constructor.
This change resolves the inconsistency by changing the name and value setters to require valid strings in accordance with RFC 6265. The effectively mandatory constructor parameters are embraced and are made actually mandatory.
This change reduces the surprising and undocumented inconsistent behavior of the Cookie class, and replaces it with meaningful and useful behavior in a way that should minimize breakage for correct users of the class.
Expected impact
Invalid constructor calls are now compile time errors
Code that attempted to construct a cookie with Cookie() or Cookie(string) instead of passing both optional parameters are now compile time errors instead of runtime errors. This code was already wrong and would now be flagged.
name and value setters
Code that assigned strings to the name and value setters that don't follow RFC 6265 will now throw an runtime error instead. This also forbids null and could break code that made a cookie with valid parameters, and then uninitialized it, or stored invalid name/value strings in it. A quick search failed to identify any such code. If it exists, it can be changed to keep track of the values in another way.
Steps for mitigation
Normal reasonable code shouldn't need to make any changes.
The Cookie constructor would already have been invoked with two RFC 6265 valid parameters, or there would have been a runtime error and the code wouldn't have done anything meaningful. Such code can be fixed to construct a Cookie properly or be deleted.
The name and value setters would probably only have been called with RFC 6265 valid parameters. Modifying a cookie is probably comparatively rare compared to constructing a new one. If code is relying on storing null or invalid strings (per RFC 6265) as the name or value, it can use a more general key-value store instead such as map.
Implementation
A proposed implementation of this breaking change: https://dart-review.googlesource.com/c/sdk/+/103840
cc @aadilmaan
cc @lrhn
Intended change
The
Cookieconstructor is changed fromto
The
Cookie.nameandCookie.valuesetters now validate the name and values are valid according to RFC 6265 and cannot be null.Rationale
The
Cookie()constructor originally allowed a null name and value, however the Dart 1.3.0 release (2014) introduced a bug that meant thenameandvalueparameters could not be null, because a NoSuchMethod exception would be thrown. Effectively the optional parameters became mandatory and the class could not be instantiated without passing two non-null Strings.The name and string constructor parameters have been checked for RFC 6265 validity for a long time now. However the
nameandvaluesetters were completely unchecked and allowed any string and even null, making it possible to construct an invalid cookie that the other side would reject. This is inconsistent with the strict checking in the constructor.This change resolves the inconsistency by changing the
nameandvaluesetters to require valid strings in accordance with RFC 6265. The effectively mandatory constructor parameters are embraced and are made actually mandatory.This change reduces the surprising and undocumented inconsistent behavior of the Cookie class, and replaces it with meaningful and useful behavior in a way that should minimize breakage for correct users of the class.
Expected impact
Invalid constructor calls are now compile time errors
Code that attempted to construct a cookie with
Cookie()orCookie(string)instead of passing both optional parameters are now compile time errors instead of runtime errors. This code was already wrong and would now be flagged.name and value setters
Code that assigned strings to the
nameandvaluesetters that don't follow RFC 6265 will now throw an runtime error instead. This also forbids null and could break code that made a cookie with valid parameters, and then uninitialized it, or stored invalid name/value strings in it. A quick search failed to identify any such code. If it exists, it can be changed to keep track of the values in another way.Steps for mitigation
Normal reasonable code shouldn't need to make any changes.
The Cookie constructor would already have been invoked with two RFC 6265 valid parameters, or there would have been a runtime error and the code wouldn't have done anything meaningful. Such code can be fixed to construct a Cookie properly or be deleted.
The
nameandvaluesetters would probably only have been called with RFC 6265 valid parameters. Modifying a cookie is probably comparatively rare compared to constructing a new one. If code is relying on storing null or invalid strings (per RFC 6265) as the name or value, it can use a more general key-value store instead such as map.Implementation
A proposed implementation of this breaking change: https://dart-review.googlesource.com/c/sdk/+/103840
cc @aadilmaan
cc @lrhn