I think we should deprecate first-byte-timeout:
-
For many HTTP clients (including fetch), the first (non-error) event observable after dispatching a request is the end of response headers (e.g. \r\n\r\n for HTTP/1.1). The first-byte-timeout instead wants to wait for one more byte: "the first byte of the Response body". I'm not familiar with any reason to treat that byte as special.
-
End of response headers already has an event: the async return of response. If someone wants a timeout there they can use a regular timer that races the response.
-
The timeout between end of response headers and the first byte of the response body can instead be covered by between-bytes-timeout. This would technically be a breaking change but I believe wasmtime-wasi-http and jco already behave this way, so I suggest that we just document that both the original spec behavior and the current implementations' behaviors are acceptable.
I think we should deprecate
first-byte-timeout:For many HTTP clients (including
fetch), the first (non-error) event observable after dispatching a request is the end of response headers (e.g.\r\n\r\nfor HTTP/1.1). Thefirst-byte-timeoutinstead wants to wait for one more byte: "the first byte of the Response body". I'm not familiar with any reason to treat that byte as special.End of response headers already has an event: the async return of
response. If someone wants a timeout there they can use a regular timer that races the response.The timeout between end of response headers and the first byte of the response body can instead be covered by
between-bytes-timeout. This would technically be a breaking change but I believewasmtime-wasi-httpand jco already behave this way, so I suggest that we just document that both the original spec behavior and the current implementations' behaviors are acceptable.