Per RFC 6265, which is the cookie spec you seem to use, the valid chars for cookie names is defined [1] by RFC 2616 (since obsoleted by the 723x series; but agreeing on this issue [2]).
The cookie name must be a 'token', which is incidentally the exact same rule as for HTTP header names. 'token' evaluates to one or more of the following ASCII visible characters:
Right now you allow any valid JSON object key to be set as a cookie name.
EDIT: To be more precise, your defaults are fine as they URLencode the key too, along with the value. But the defaults are overridable and affect both the cookie key and value simultaneously. Allowing the value encoding to be overridden would be useful, while allowing the name encoding to be overridden can cause the cookie to fall out of spec.
I see, so I could add a `cookies.encodevalue()` and default it to `cookies.encode`. However, I think that'd just add too much noise to it so I will just add a warning. Thank you.
Per RFC 6265, which is the cookie spec you seem to use, the valid chars for cookie names is defined [1] by RFC 2616 (since obsoleted by the 723x series; but agreeing on this issue [2]).
The cookie name must be a 'token', which is incidentally the exact same rule as for HTTP header names. 'token' evaluates to one or more of the following ASCII visible characters:
Right now you allow any valid JSON object key to be set as a cookie name.EDIT: To be more precise, your defaults are fine as they URLencode the key too, along with the value. But the defaults are overridable and affect both the cookie key and value simultaneously. Allowing the value encoding to be overridden would be useful, while allowing the name encoding to be overridden can cause the cookie to fall out of spec.
[1] https://tools.ietf.org/html/rfc2616#section-2.2
[2] https://tools.ietf.org/html/rfc7230#section-3.2.6