docs: Correct comments in HeaderValue::from_maybe_shared_unchecked.#822
docs: Correct comments in HeaderValue::from_maybe_shared_unchecked.#822PiotrSikora wants to merge 1 commit intohyperium:masterfrom
Conversation
Signed-off-by: Piotr Sikora <code@piotrsikora.dev>
| /// `src` must contain valid UTF-8. In a release build it is undefined | ||
| /// behaviour to call this with `src` that is not valid UTF-8. | ||
| /// `src` must contain valid HTTP field value. In a release build it is | ||
| /// undefined behaviour to call this with `src` that is not valid. |
There was a problem hiding this comment.
@tottoto while we're here, could you clarify what did you mean by "undefined behaviour" (added in 63e7d63)?
While the HeaderValue that's created from invalid HTTP field value would indeed contain non-compliant HTTP field value, it would produce an error in to_str() or when used with other "checked" variants, so it's not clear what kind of "undefined behaviour" did you mean here.
Perhaps we could change it to something more descriptive? This function is already unnecessarily marked as unsafe, so using "undefined behaviour" in this context raises a bit more red flags than it should, IMHO.
Notably, majority of production deployments allow more relaxed parsing of HTTP field values than required by RFC9110 (e.g. see WHATWG), so it would be helpful if those could be stored in HeaderValue without worrying about "undefined behaviour".
1 participant
No description provided.