HttpHeadersImpl should sanitize header values to prevent obs-fold sequences (RFC 7230 §3.2.4)

[jsquire]

Description

The createHttpHeaders function (backed by HttpHeadersImpl in sdk/core/ts-http-runtime/src/httpHeaders.ts) stores header values using String(value).trim(). While this trims leading/trailing whitespace, it does not strip or reject illegal characters — specifically CR (\r) and LF (\n) sequences — from the value.

RFC 7230, section 3.2.4 states:

A sender MUST NOT generate a message that includes line folding (i.e., that has any field-value that contains a match to the obs-fold rule) unless the message is intended for packaging within the message/http media type.

Including \r\n in a header value can lead to header injection in HTTP/1.x contexts where the raw header is emitted without further encoding by the transport.

Motivation

• Standards compliance: Aligns with RFC 7230 §3.2.4 requirements for senders.
• Defense-in-depth: While the Core pipeline intentionally gives callers full control over request/response data (so this is not a security vulnerability), stripping these characters is a low-cost safeguard that prevents unexpected behavior.
• Caller experience: Callers who accidentally pass multi-line strings won't produce malformed HTTP messages silently.

Suggested Behavior

When set(name, value) is called, the implementation should strip or reject \r, \n, and \r\n sequences from the value (or at minimum, characters matching the obs-fold production). A reasonable approach would be to strip these characters silently (similar to how leading/trailing whitespace is already trimmed), though throwing on invalid input is also defensible.

Affected Code

• sdk/core/ts-http-runtime/src/httpHeaders.ts — HttpHeadersImpl.set()