Open Eijebong opened 6 years ago
Some implementation notes to remember:
from_str
, from_bytes
, and from_shared
. The value in these functions should be trimmed.from_static
should usually be called with compile-time string literals, it may be best to panic if the string starts or ends with whitespace. (Though, it is also possible to trim a static string to get a shorter static string...)Hi Sean, Hi Bastien
I considered writing a patch for that but I have one question. Shouldn't HeaderValue::from_bytes("coucou \t ".as_bytes())
rather return an error?
The rfc is about what parsers are expected to do. A correct parser should never create a value with leading or trailing whitespace anyway. So it rather makes sense to signal an incorrect usage instead of silently sanitizing.
Moreover, I've checked the implementation in hyper and it already trims leading whitespace but not trailing whitespace ( https://github.com/seanmonstar/httparse/blob/3aad4fac259e944b82aaf1af233624b2f98b85d9/src/lib.rs#L621 ) AND it uses the unsafe constructor for HeaderValue ( https://github.com/hyperium/hyper/blob/8f9174746660c52f7aa9ae67dd77dbd5200a136f/src/proto/h1/role.rs#L50 ) which is not expected to trim whitespace according to this description. I think we rather have to fix trailing whitespace in httparse and make constructing a HeaderValue with leading or trailing whitespace an error.
What's you opinion?
I think it's probably fair to return an error instead of trimming automatically.
As stated here,
Here's a test case that should be passing: