You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I came here via an unexpected panic in my tide webserver, but I think the problem belongs here.
When I'm using a cookie that might be a bit "odd" like password=Â , the calling library (async-h1 or tide) is calling append_header from request.rs, then append and insert within the headers/headers.rs file to set that header. On line 54 it says: let values: HeaderValues = values.to_header_values().unwrap().collect();
which fails and panics with a Result::unwrap() on an Err value: String slice should be valid ASCII.
I think those functions should have a result of type Result<T, E> if these functions can fail in such circumstances.
Specifications for newly defined fields SHOULD limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB. A recipient SHOULD treat other allowed octets in field content (i.e., obs-text) as opaque data.
To me this sounds as if http-rs treats this incorrectly. Instead of causing an error, the RFC indicated non-ascii octets should generally be preserved in some way, at least as i read it.
Activity
Fishrock123 commentedon Jan 4, 2024
In the past, http-rs held tight to disallowing things disallowed by existing http rfcs.
However in RFC 9110 "HTTP Semantics" (June 2022) under the "Field Values" (5.5) section it says:
To me this sounds as if http-rs treats this incorrectly. Instead of causing an error, the RFC indicated non-ascii octets should generally be preserved in some way, at least as i read it.
OneOfOne commentedon Apr 8, 2024
this is fixed in OneOfOne@82270e7