The real is that the server is allowed to defer decisions about authentication and authorization until it has seen some or all of the request body, therefore th

The real is that the server is allowed to defer decisions about authentication and authorization until it has seen some or all of the request body, therefore the server might not respond until it has seen part of the body, but the user-agent wants to know whether it can get an immediate response to a POST/PUT in order to avoid sending the body until it knows the server is ready to sink it, and the user-agent is resource constrained and cannot cache the request body, say: - the user-agent wants an early 2xx/4xx from the server - the server is allowed to defer - the user-agent has no reliable way to force the server to decide early -- the user-agent can only ask nicely for a 100-continue / early 2xx/4xx - and the user-agent has no reliable way to determine if the server does support Expect: 100-continue What the user-agent wants is for the server to send any 3xx/401 responses early, else commit to not-401 by sending 100-continue. The server can still defer 2xx/403 responses, though preferably not 403s, until it sees some/all of the request body. The only fix I can think of is to REQUIRE that OPTIONS responses indicate whether the server supports this or not. An HTTP/2 or 3 gateway to an HTTP/1.1 server (or vice versa) could be configured to indicate support / no support for Expect: 100-continue. In particular, there is no way for a new version of HTTP to give a user-agent a way to force the server to support early decisions. The servers exist already, and the are as they are.