ruvoy 0.2.1-x86_64-linux → 0.3.0-x86_64-linux

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 6d90daa6f044467b4a5a0059c96debe320f989b6e1acf7fe9194a4be23bbf446
-  data.tar.gz: 3c55f4b9274f9abd01a6c6a5e480b58ab9cb3f7e3e32cc2ae838a85c18bc4020
+  metadata.gz: 267edfc5bd783c89f4cdf67a901208abc8bdc864731e317f54844a90edccdc07
+  data.tar.gz: 3f2606403c1b214ac244e22bd4eb9bb93fb6a015fbc06cdc57412b7cc9822323
 SHA512:
-  metadata.gz: d06b5d3a5e2d003593f0a7ecb7d39276485fdbaee66b12d72638009de68b8ab6988683d6f53fec7faccb62c33a3cf70c52bda4198427b4d422bc0c04ed8c5cba
-  data.tar.gz: a8866d45815b5321f12e1ebdcef5afabf077487ee96387d7a3f923b333e1b06b089ec8feccf096890cdd55edada3da8c8de370ffa750545ff202f6a153d899c1
+  metadata.gz: 04dff6a6abdaaf19a26d522a66d72c334ae59dc2e7b60bd9b149f0196df7718d90a5e41a76e43a743c64353620da088772ced2d13ce00bd32aaf3fa133194405
+  data.tar.gz: 4da1c6f133dd80441c1966eb396b1fd6b898d84a094dc8340257cb9b5e758648f5e55130e365a6296aff601426d65c776fde20dad770f784bffad023fd4541b4

data/README.md

@@ -141,6 +141,10 @@ kept, in memory up to 128 KiB and in a temporary file beyond that, so
 Rack versions expect. Raw socket hijacking
 (`rack.hijack`) is not supported; the connection always belongs to Envoy.
 
+WebSocket and other upgrades use Rack 3's `rack.protocol` with a streaming
+body instead, over HTTP/1.1 and HTTP/2, once Envoy allows them
+(`upgrade_configs`, plus `allow_connect` for HTTP/2).
+
 A response body that fails after its headers are already on the wire resets
 the stream, so the client sees an error rather than a short body that looks
 complete.
@@ -276,28 +280,18 @@ one request overlap. A repeated response header arrives as an Array.
 - `call` buffers the response whole, so `max_response_bytes` bounds what one
   call can hold in memory.
 
-`stream` takes the same arguments and returns once the response head is in.
-The body yields the response as it arrives and can be returned as the Rack
-response, so a proxy is one line:
+`stream` takes the same arguments but returns once the head is in, with a
+body that streams and can be returned as the Rack response, so a proxy is one
+line:
 
 ```ruby
 run ->(env) { env["ruvoy.upstream"].stream("api", env["REQUEST_METHOD"], env["PATH_INFO"], body: env["rack.input"]) }
 ```
 
-- The request body may be a String or anything that responds to `read`, such
-  as `rack.input`. One that ends within its first 64 KiB goes with its length,
-  an empty one as none, and a longer one chunked while the response comes down.
-- `idle_timeout:` bounds the wait for the head and between chunks, `timeout_ms`
-  by default, and raises `Ruvoy::UpstreamTimeout`. `timeout:` bounds the whole
-  exchange and is unset by default: Envoy answers 504 before the head, and
-  resets the stream after it.
-- Envoy applies no flow control to a stream a module starts, so at most
-  `upstream.stream_buffer_bytes` (default 1 MiB) of the response waits for a
-  slow reader. Past that the stream is reset and the reader gets
-  `Ruvoy::UpstreamOverflow`. The request body is held to the same budget until
-  Envoy takes it; what Envoy buffers after that is not bounded by Ruvoy.
-- Closing the body before its end, or finishing the request, resets the
-  stream. `body.trailers` holds the upstream's trailers once the body has ended.
+Envoy applies no flow control to it, so a reader that falls more than
+`upstream.stream_buffer_bytes` (1 MiB by default) behind has the stream reset.
+With `protocol: "websocket"`, the response upgrades the client too and relays
+both ways.
 
 [`examples/extensions`](examples/extensions) runs both against a stand-in
 service, including two calls from one request overlapping.

data/lib/ruvoy/version.rb

@@ -3,5 +3,5 @@
 module Ruvoy
   # Kept in step with the Cargo workspace version by test/e2e/cli_test.rb: the
   # gem and the module it carries are the same release.
-  VERSION = "0.2.1"
+  VERSION = "0.3.0"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: ruvoy
 version: !ruby/object:Gem::Version
-  version: 0.2.1
+  version: 0.3.0
 platform: x86_64-linux
 authors:
 - Zixin Zhou