Enforce character restriction for AsciiMarshaller

[carl-mastrangelo]

AsciiMarshaller is used for HTTP2 Headers. Since HTTP2 is more restrictive about what ascii characters can be used, AM should either be more clear about what characters are accepted, or enforce such restrictions.

[ejona86]

So it already specifies "ASCII string that contains only printable characters and space". It maybe should specify that leading and trailing whitespace may be discarded, and we may want to prohibit the use of comma to be able to deal with proxies combining multi-valued headers.

[carl-mastrangelo]

@ejona86 IIRC it was something like a token68 rather than the full 95 printable character set of ascii.

[ejona86]

If you take a look at RFC 7230 §3.2, this is the important part (with obs-fold and obs-text removed, since they are obsolete):

field-value    = *field-content
field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar    = VCHAR

Combined with this from §1.2/RFC 5234 §B.1:

HTAB           =  %x09
                       ; horizontal tab
SP             =  %x20
VCHAR          =  %x21-7E
                       ; visible (printing) characters

I mention removal of leading and trailing whitespace because of §3.2.4:

A field value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred
for consistent readability by humans. The field value does not
include any leading or trailing whitespace: OWS occurring before the
first non-whitespace octet of the field value or after the last
non-whitespace octet of the field value ought to be excluded by
parsers when extracting the field value from a header field.

I mention disallowing comma because of §3.2.2:

A recipient MAY combine multiple header fields with the same field
name into one "field-name: field-value" pair, without changing the
semantics of the message, by appending each subsequent field value to
the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field
value

Also of value from §3.2.2:

A sender MUST NOT generate multiple header fields with the same field
name in a message unless either the entire field value for that
header field is defined as a comma-separated list [i.e., #(values)]
or the header field is a well-known exception (as noted below).

The only special case is "Set-Cookie."

Where comma-separated list is defined in §7:

The full form is "#element"
indicating at least and at most elements, each separated by a
single comma (",") and optional whitespace (OWS).

[ejona86]

We'll be prohibiting comma for the beta, to give us time to figure out how we want to handle it. (we would still have to accept it, because it is valid for HTTP, but we wouldn't generate it)

[zhangkun83]

Shall we convert this issue into "enforcing character restrictions?"