[Web-SIG] HTTP 1.1 Expect/Continue handling

[Brian Smith]

1. The WSGI gateway must send the response headers immediately when the application yields its first non-empty string.

2. When there is an "100-continue" token in the request "Expect:" header, the WSGI gateway is allowed to delay sending the "100 Continue" response until the application reads from environ["wsgi.input"]. 

Consequently, if there is a 100-continue expectation, then a WSGI application must not read from wsgi.input after yielding its first non-empty string. 

For example, the following application results in undefined (probably erroneous) behavior:

	def application(environ, start_response):
		start_response("400 Bad Request", [])
		yield "400 Bad Request"
		environ["wsgi.input"].read(1)
	
However, the following application must cause the WSGI gateway to send a 100-continue response:

	def application(environ, start_response):
		start_response("400 Bad Request", [])
		yield ""
		environ["wsgi.input"].read(1)

PEP says that "[s]ervers and gateways that implement HTTP 1.1 must provide transparent support for HTTP 1.1's "expect/continue" mechanism." Should the application be able to detect whether there is a "100-continue" token in the Expect header of the request? Or, is the WSGI gateway allowed/required to hide the token? If the application cannot reliably detect the 100-continue token, then this implies an ordering constraint between yielding output and reading input that is not mentioned anywhere in the PEP.

Another consequence is that an application cannot explicitly respond with a "100 Continue" itself, like this:
	
      def application(environ, start_response):
		start_response("100 Continue", [])
		yield ""
		start_response("200 OK", [])
		yield "OK"

The reasons is that start_response cannot be called twice except when an exception is detected, and also the "100 Continue" would not be sent until right before the "200 OK" was sent anyway.

Regards,
Brian