4 ms·

Is that really a HTTP/[2|3] problem, or a problem of those servers? As far as I understood the HTTP/2 spec (have read this, but not HTTP/3), it is allowed for

Is that really a HTTP/[2|3] problem, or a problem of those servers? As far as I understood the HTTP/2 spec (have read this, but not HTTP/3), it is allowed for servers to send an arbitrary amount of informational headers (incl. 100-continue) before sending the actual headers and response body. So everything to handle these kinds of requests should be in place. If the server ignores the "Expect: 100-continue" there is obviously nothing the other side can do, but that's the same in HTTP/1.1. What I am a bit unsure about is actually how things like "transfer-encoding: chunked" or the various "connection" headers are supposed to be handled in servers/clients/libraries that are supposed to handle HTTP/1.1 and HTTP/2. Is this supposed to be automatically set on the lower level, depending on the actual protocol type. And the application level HTTP client or handler on server just sees the body as a stream? I'm not sure if that happens currently in common libraries, or whether they would forward these things if a client is connected via HTTP/1.1 and not when it's connected via HTTP/2.

cryptonector 8y ago
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.
treve 8y ago
> What I am a bit unsure about is actually how things like "transfer-encoding: chunked" or the various "connection" headers are supposed to be handled in servers/clients/libraries that are supposed to handle HTTP/1.1 and HTTP/2 As you suspected these headers are 'special' and don't exist in HTTP/2.
cryptonector 8y ago
> What I am a bit unsure about is actually how things like "transfer-encoding: chunked" or the various "connection" headers are supposed to be handled in servers/clients/libraries that are supposed to handle HTTP/1.1 and HTTP/2. Is this supposed to be automatically set on the lower level, depending on the actual protocol type. And the application level HTTP client or handler on server just sees the body as a stream? I'm not sure if that happens currently in common libraries, or whether they would forward these things if a client is connected via HTTP/1.1 and not when it's connected via HTTP/2. Section 8.1.2.2 of RFC 7540 [0] covers most of what you ask except that it doesn't explain how chunked transfer-encoding maps to HTTP/2, and section 8.1.3 [1] shows an example of mapping chunked transfer-encoding onto HTTP/2 data frames. Basically, in HTTP/2 all transfers are necessarily "chunked" into DATA frames [2] (necessarily because of multiplexing of channels!), and Content-Length -when present- merely indicates what all the chunks must add up to. [0] https://tools.ietf.org/html/rfc7540#section-8.1.2.2 [1] https://tools.ietf.org/html/rfc7540#section-8.1.3 [2] https://tools.ietf.org/html/rfc7540#section-6.1
- Matthias247 8y ago
  I am aware how bodies are streamed in HTTP/2 (I have written an implementation). What I am not sure about is how libraries on client and server side are expected to handle this kind of information. A Lot of servers and client libraries might display "transfer-encoding: chunked" to their user, even though that wouldn't be seen if the connection was established via HTTP/2. It's more of a question of "how to hide those protocol differences from the user while still allowing them to set and access all information if required". And the question whether the HTTP ecosystem already embraces that, or whether most libraries still expose all the HTTP/1.1-only ways to the user.

cryptonector 8y ago

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.

treve 8y ago

cryptonector 8y ago

> What I am a bit unsure about is actually how things like "transfer-encoding: chunked" or the various "connection" headers are supposed to be handled in servers/clients/libraries that are supposed to handle HTTP/1.1 and HTTP/2. Is this supposed to be automatically set on the lower level, depending on the actual protocol type. And the application level HTTP client or handler on server just sees the body as a stream? I'm not sure if that happens currently in common libraries, or whether they would forward these things if a client is connected via HTTP/1.1 and not when it's connected via HTTP/2. Section 8.1.2.2 of RFC 7540 [0] covers most of what you ask except that it doesn't explain how chunked transfer-encoding maps to HTTP/2, and section 8.1.3 [1] shows an example of mapping chunked transfer-encoding onto HTTP/2 data frames. Basically, in HTTP/2 all transfers are necessarily "chunked" into DATA frames [2] (necessarily because of multiplexing of channels!), and Content-Length -when present- merely indicates what all the chunks must add up to. [0] https://tools.ietf.org/html/rfc7540#section-8.1.2.2 [1] https://tools.ietf.org/html/rfc7540#section-8.1.3 [2] https://tools.ietf.org/html/rfc7540#section-6.1

Matthias247 8y ago
I am aware how bodies are streamed in HTTP/2 (I have written an implementation). What I am not sure about is how libraries on client and server side are expected to handle this kind of information. A Lot of servers and client libraries might display "transfer-encoding: chunked" to their user, even though that wouldn't be seen if the connection was established via HTTP/2. It's more of a question of "how to hide those protocol differences from the user while still allowing them to set and access all information if required". And the question whether the HTTP ecosystem already embraces that, or whether most libraries still expose all the HTTP/1.1-only ways to the user.