unnecessary use of 1#element for header field definitions

[royfielding]

When working on #164 I noticed that our existing use of 1#element (header fields requiring at least one list item) is kind of pointless. The following fields use it:

 Cache-Control   = 1#cache-directive
 Transfer-Encoding = 1#transfer-coding
 Connection        = 1#connection-option
 Upgrade          = 1#protocol
 Trailer = 1#field-name
 Via = 1#( received-protocol RWS received-by [ RWS comment ] )
 Content-Encoding = 1#content-coding
 Content-Language = 1#language-tag
 If-Match = "*" / 1#entity-tag
 If-None-Match = "*" / 1#entity-tag
 Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
 Accept-Language = 1#( language-range [ weight ] )
 Vary = "*" / 1#field-name
 WWW-Authenticate = 1#challenge
 Proxy-Authenticate = 1#challenge

It is also used (incorrectly?) within Byte Ranges fields as

 byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )
 acceptable-ranges = 1#range-unit / "none"

We should audit these because it makes more sense to handle empty fields as non-error conditions.

[mnot]

If you mean that we should change them to #rule rather than 1#rule, I tend to agree -- but IIRC there was a reason this was done. @reschke?

[reschke]

See #164. This change would reduce the complexity of the list rule. We'd just have to put the "minimally one instance" constraint into prose.

[mnot]

I think Roy's point is that we don't need to limit to a minimum number of elements -- even in prose.

[reschke]

Well, for at least some of these, we may have to say what it means if there is none.

[mnot]

From Roy's list, I've ticked the ones that I think that's true for:

• Cache-Control = 1#cache-directive
• Transfer-Encoding = 1#transfer-coding
• Connection = 1#connection-option
• Upgrade = 1#protocol
• Trailer = 1#field-name
• Via = 1#( received-protocol RWS received-by [ RWS comment ] )
• Content-Encoding = 1#content-coding
• Content-Language = 1#language-tag
• If-Match = "*" / 1#entity-tag
• If-None-Match = "*" / 1#entity-tag
• Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
• Accept-Language = 1#( language-range [ weight ] )
• Vary = "*" / 1#field-name
• WWW-Authenticate = 1#challenge
• Proxy-Authenticate = 1#challenge

You could argue that Accept-* need them too, but I think the right think will happen regardless...

[royfielding]

I think that when an empty header field indicates an error instead of just an empty list, we should define it as 1#value. When a field might be generated, truncated, or whitespaced-out by multiple implementations in a chain of communication, allowing the field to be sent empty is a common simplification (or at least a common error case that only wastes a little bandwidth). This is particularly true if we expect extensions or intermediaries to drop or append some values, as is the case for all of those fields except If-Match.

[mnot]

That sounds about right. Although we should specify that error handling in prose too, I think.

[mnot]

AIUI we want to remove 1# from the top level of all field values EXCEPT those ticked above (If-Match, If-None-Match, Vary, WWW-Authenticate, Proxy-Authenticate), because in each of those cases, an empty value is considered an error (typically, the intended semantics are unclear and therefore interop could suffer).

Questions:

1. Is that correct, generally speaking?
2. Is that specific list of headers correct?
3. For the headers that we want to keep as 1#, should we define the semantics of an empty field value (if only to say that they're not defined, so it isn't interoperable)?

[reschke]

• *-authenticate: same as a non-empty list containing only unknown auth schemes

[mnot]

That sounds like we want to remove 1# from *-Authenticate.