Expect should be a list header

[mnot]

In bis, we locked down Expect to a single value, 100-continue. That's probably a bug; it needs to act like a list header still, even though it only has one allowed value. We might have to define error handling here too.

[mcmanus]

ietf104: no concerns raised about adopting a list format

[reschke]

I guess we then need to pull in the full old ABNF:

   Expect       =  "Expect" ":" 1#expectation

   expectation  =  "100-continue" | expectation-extension
   expectation-extension =  token [ "=" ( token | quoted-string )
                            *expect-params ]
   expect-params =  ";" token [ "=" ( token | quoted-string ) ]

and then simplify it to:

   Expect       =  "Expect" ":" 1#expectation

   expectation =  token [ "=" ( token | quoted-string ) *expect-params ]
   expect-params =  ";" token [ "=" ( token | quoted-string ) ]

...and then define that the only expection that exists is "100-continue" with no parameters...

[reschke]

I wonder whether we can use parameter here - note that the old ABNF comes from 2616 which had implied LWS.

[annevk]

From other header parsing tests I've done I'd expect the processing model to be "split on comma and strip whitespace" and then see if any resulting token is an ASCII-case-insensitive match for 100-continue.

[reschke]

This introduced a bug - "*parameter" does not work, as "parameter" does not include the ";" delimiter.

[mnot]

This can now be closed, correct?

[reschke]

Yes.