Handling of the HTTP Expect header was implemented in #316. However, the http module simply checks to see if the header's value is 100-continue.

If it is, it applies logic to either raise the checkContinue event or simply send a HTTP/1.1 100 Continue.

However, if it is anything else, http simply ignores the header. This is a violation of the spec, which allows for values other than 100-continue.

A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request MUST respond with appropriate error status. The server MUST respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with the request, some other 4xx status.

This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing an Expect field that includes an expectation-extension that it does not support, it MUST respond with a 417 (Expectation Failed) status.

Application authors should not have to manually check the Expect header just to properly handle a protocol detail. http should be able to send a 417 automatically.

Of course, the flip side of this is that application authors should be able to handle custom Expect values.

I propose:

1. By default, respond with a 417 error for unknown Expect values.
2. Extend the current handling of the Expect header to allow applications to hook in and prevent the default response.

For example, we could add a checkExpectation event that works somewhat like checkContinue: if there are no listeners, respond with a 417. If there are listeners, just pass the request and response objects to the listeners.

Alternatively, we could add an option to http.Server that controls whether or not unknown expectations are automatically handled. If disabled, we'd leave it up to the app's normal request handling code, which would have to explicitly check the Expect header's value.