Ensure that browsers never send a malformed request except by explicit request from scripts

[DemiMarie]

What is the issue with the Fetch Standard?

The Fetch Standard allows field values to contain control characters that are not valid in HTTP. In HTTP/2 and later, this makes a request malformed, and servers are required to close the stream. If it is possible for a header that the user agent sends automatically to have an invalid value, this could cause problems. For instance, setting a Cookie header with an invalid value could prevent the user from navigating to a website. Furthermore, the handling of fields with invalid values differs between server implementations: HAProxy and NGINX are permissive, Varnish is strict, and nghttp3 silently discards headers if the field has an invalid value. Envoy goes further and closes the entire connection.

To avoid such problems, it would be best to ensure that invalid HTTP field values are only ever sent by explicit request from scripts, and only for fields that scripts have complete control over the values of. This ensures two useful properties:

1. Requests will always be well-formed unless a script explicitly chooses to make a malformed request.
2. Regardless of how servers handle malformed values, information that is under the control of the user agent will be received correctly.

If these properties are already ensured, it would be useful to document this.

[annevk]

I'm not sure what 2 means, but 1 is ensured. I don't think it has to be stated again however, it already follows from everything that is stated today.

[DemiMarie]

I'm not sure what 2 means, but 1 is ensured. I don't think it has to be stated again however, it already follows from everything that is stated today.

2 means that scripts cannot cause forbidden header names to have values that violate RFC9110.

[annevk]

I think that also clearly follows from the requirements laid out in the draft.