cybrid_api_id_ruby 0.129.1137 → 0.129.1138

data/vendor/bundle/ruby/4.0.0/gems/http-2-1.2.3/README.md

@@ -0,0 +1,298 @@
+# HTTP-2
+
+[![Gem Version](https://badge.fury.io/rb/http-2.svg)](http://rubygems.org/gems/http-2)
+[![Build status](https://github.com/igrigorik/http-2/actions/workflows/ci.yml/badge.svg)](https://github.com/igrigorik/http-2)
+
+Pure Ruby, framework and transport agnostic, implementation of HTTP/2 protocol and HPACK header compression with support for:
+
+
+* [Binary framing](https://hpbn.co/http2/#binary-framing-layer) parsing and encoding
+* [Stream multiplexing](https://hpbn.co/http2/#streams-messages-and-frames) and [prioritization](https://hpbn.co/http2/#stream-prioritization)
+* Connection and stream [flow control](https://hpbn.co/http2/#flow-control)
+* [Header compression](https://hpbn.co/http2/#header-compression) and [server push](https://hpbn.co/http2/#server-push)
+* Connection and stream management
+* And more... see [API docs](https://www.rubydoc.info/gems/http-2)
+
+Protocol specifications:
+
+* [Hypertext Transfer Protocol Version 2 (RFC 7540)](https://httpwg.github.io/specs/rfc7540.html)
+* [HPACK: Header Compression for HTTP/2 (RFC 7541)](https://httpwg.github.io/specs/rfc7541.html)
+
+
+## Getting started
+
+```bash
+$> gem install http-2
+```
+
+This implementation makes no assumptions as how the data is delivered: it could be a regular Ruby TCP socket, your custom eventloop, or whatever other transport you wish to use - e.g. ZeroMQ, [avian carriers](http://www.ietf.org/rfc/rfc1149.txt), etc.
+
+Your code is responsible for feeding data into the parser, which performs all of the necessary HTTP/2 decoding, state management and the rest, and vice versa, the parser will emit bytes (encoded HTTP/2 frames) that you can then route to the destination. Roughly, this works as follows:
+
+```ruby
+require 'http/2'
+
+socket = YourTransport.new
+
+conn = HTTP2::Client.new
+conn.on(:frame) {|bytes| socket << bytes }
+
+while bytes = socket.read
+ conn << bytes
+end
+```
+
+Checkout provided [client](example/client.rb) and [server](example/server.rb) implementations for basic examples.
+
+
+### Connection lifecycle management
+
+Depending on the role of the endpoint you must initialize either a [Client](lib/http/2/client.rb) or a [Server](lib/http/2/server.rb) object. Doing so picks the appropriate header compression / decompression algorithms and stream management logic. From there, you can subscribe to connection level events, or invoke appropriate APIs to allocate new streams and manage the lifecycle. For example:
+
+```ruby
+# - Server ---------------
+server = HTTP2::Server.new
+
+server.on(:stream) { |stream| ... } # process inbound stream
+server.on(:frame)  { |bytes| ... }  # encoded HTTP/2 frames
+
+server.ping { ... } # run liveness check, process pong response
+server.goaway # send goaway frame to the client
+
+# - Client ---------------
+client = HTTP2::Client.new
+client.on(:promise) { |stream| ... } # process push promise
+
+stream = client.new_stream # allocate new stream
+stream.headers({':method' => 'post', ...}, end_stream: false)
+stream.data(payload, end_stream: true)
+```
+
+Events emitted by the connection object:
+
+<table>
+  <tr>
+    <td><b>:promise</b></td>
+    <td>client role only, fires once for each new push promise</td>
+  </tr>
+  <tr>
+    <td><b>:stream</b></td>
+    <td>server role only, fires once for each new client stream</td>
+  </tr>
+  <tr>
+    <td><b>:frame</b></td>
+    <td>fires once for every encoded HTTP/2 frame that needs to be sent to the peer</td>
+  </tr>
+</table>
+
+Connection shutdown happens in two steps. Once a GOAWAY frame is sent or
+received, no new streams may be opened: `closed?` turns true and `new_stream`
+raises `ConnectionClosed` — new work belongs on a new connection. After a
+graceful GOAWAY (`:no_error`), streams the peer may still complete keep
+running: `closing?` distinguishes this draining state, in which the connection
+keeps processing frames — including connection-level flow control — until the
+last tracked stream closes. Streams the GOAWAY refused (id above its
+last-stream-id) are reported via the `:goaway` event, so their callers can
+retry them on a fresh connection.
+
+### Stream lifecycle management
+
+A single HTTP/2 connection can [multiplex multiple streams](https://hpbn.co/http2/#request-and-response-multiplexing) in parallel: multiple requests and responses can be in flight simultaneously and stream data can be interleaved and prioritized. Further, the specification provides a well-defined lifecycle for each stream (see below).
+
+The good news is, all of the stream management, and state transitions, and error checking is handled by the library. All you have to do is subscribe to appropriate events (marked with ":" prefix in diagram below) and provide your application logic to handle request and response processing.
+
+```
+                      +--------+
+                 PP   |        |   PP
+             ,--------|  idle  |--------.
+            /         |        |         \
+           v          +--------+          v
+    +----------+          |           +----------+
+    |          |          | H         |          |
+,---|:reserved |          |           |:reserved |---.
+|   | (local)  |          v           | (remote) |   |
+|   +----------+      +--------+      +----------+   |
+|      | :active      |        |      :active |      |
+|      |      ,-------|:active |-------.      |      |
+|      | H   /   ES   |        |   ES   \   H |      |
+|      v    v         +--------+         v    v      |
+|   +-----------+          |          +-----------+  |
+|   |:half_close|          |          |:half_close|  |
+|   |  (remote) |          |          |  (local)  |  |
+|   +-----------+          |          +-----------+  |
+|        |                 v                |        |
+|        |    ES/R    +--------+    ES/R    |        |
+|        `----------->|        |<-----------'        |
+| R                   | :close |                   R |
+`-------------------->|        |<--------------------'
+                      +--------+
+```
+
+For sake of example, let's take a look at a simple server implementation:
+
+```ruby
+conn = HTTP2::Server.new
+
+# emits new streams opened by the client
+conn.on(:stream) do |stream|
+  stream.on(:active) { } # fires when stream transitions to open state
+  stream.on(:close)  { } # stream is closed by client and server
+
+  stream.on(:headers) { |head| ... } # header callback
+  stream.on(:data) { |chunk| ... }   # body payload callback
+
+  # fires when client terminates its request (i.e. request finished)
+  stream.on(:half_close) do
+
+    # ... generate_response
+
+    # send response
+    stream.headers({
+      ":status" => 200,
+      "content-type" => "text/plain"
+    })
+
+    # split response between multiple DATA frames
+    stream.data(response_chunk, end_stream: false)
+    stream.data(last_chunk)
+  end
+end
+```
+
+Events emitted by the [Stream object](lib/http/2/stream.rb):
+
+<table>
+  <tr>
+    <td><b>:reserved</b></td>
+    <td>fires exactly once when a push stream is initialized</td>
+  </tr>
+  <tr>
+    <td><b>:active</b></td>
+    <td>fires exactly once when the stream become active and is counted towards the open stream limit</td>
+  </tr>
+  <tr>
+    <td><b>:headers</b></td>
+    <td>fires once for each received header block (multi-frame blocks are reassembled before emitting this event)</td>
+  </tr>
+  <tr>
+    <td><b>:data</b></td>
+    <td>fires once for every DATA frame (no buffering)</td>
+  </tr>
+  <tr>
+    <td><b>:half_close</b></td>
+    <td>fires exactly once when the opposing peer closes its end of connection (e.g. client indicating that request is finished, or server indicating that response is finished)</td>
+  </tr>
+  <tr>
+    <td><b>:close</b></td>
+    <td>fires exactly once when both peers close the stream, or if the stream is reset</td>
+  </tr>
+  <tr>
+    <td><b>:priority</b></td>
+    <td>fires once for each received priority update (server only)</td>
+  </tr>
+</table>
+
+
+### Prioritization
+
+Each HTTP/2 [stream has a priority value](https://hpbn.co/http2/#stream-prioritization) that can be sent when the new stream is initialized, and optionally reprioritized later:
+
+```ruby
+client = HTTP2::Client.new
+
+default_priority_stream = client.new_stream
+custom_priority_stream = client.new_stream(priority: 42)
+
+# sometime later: change priority value
+custom_priority_stream.reprioritize(32000) # emits PRIORITY frame
+```
+
+On the opposite side, the server can optimize its stream processing order or resource allocation by accessing the stream priority value (`stream.priority`).
+
+
+### Flow control
+
+Multiplexing multiple streams over the same TCP connection introduces contention for shared bandwidth resources. Stream priorities can help determine the relative order of delivery, but priorities alone are insufficient to control how the resource allocation is performed between multiple streams. To address this, HTTP/2 provides a simple mechanism for [stream and connection flow control](https://hpbn.co/http2/#flow-control).
+
+Connection and stream flow control is handled by the library: all streams are initialized with the default window size (64KB), and send/receive window updates are automatically processed - i.e. window is decremented on outgoing data transfers, and incremented on receipt of window frames. Similarly, if the window is exceeded, then data frames are automatically buffered until window is updated.
+
+The only thing left is for your application to specify the logic as to when to emit window updates:
+
+```ruby
+conn.buffered_amount     # check amount of buffered data
+conn.window              # check current window size
+conn.window_update(1024) # increment connection window by 1024 bytes
+
+stream.buffered_amount     # check amount of buffered data
+stream.window              # check current window size
+stream.window_update(2048) # increment stream window by 2048 bytes
+```
+
+
+### Server push
+
+An HTTP/2 server can [send multiple replies](https://hpbn.co/http2/#server-push) to a single client request. To do so, first it emits a "push promise" frame which contains the headers of the promised resource, followed by the response to the original request, as well as promised resource payloads (which may be interleaved). A simple example is in order:
+
+```ruby
+conn = HTTP2::Server.new
+
+conn.on(:stream) do |stream|
+  stream.on(:headers) { |head| ... }
+  stream.on(:data) { |chunk| ... }
+
+  # fires when client terminates its request (i.e. request finished)
+  stream.on(:half_close) do
+    promise_header = { ':method' => 'GET',
+                       ':authority' => 'localhost',
+                       ':scheme' => 'https',
+                       ':path' => "/other_resource" }
+
+    # initiate server push stream
+    push_stream = nil
+    stream.promise(promise_header) do |push|
+      push.headers({...})
+      push_stream = push
+    end
+
+    # send response
+    stream.headers({
+      ":status" => 200,
+      "content-type" => "text/plain"
+    })
+
+    # split response between multiple DATA frames
+    stream.data(response_chunk, end_stream: false)
+    stream.data(last_chunk)
+
+    # now send the previously promised data
+    push_stream.data(push_data)
+  end
+end
+```
+
+When a new push promise stream is sent by the server, the client is notified via the `:promise` event:
+
+```ruby
+conn = HTTP2::Client.new
+conn.on(:promise) do |push|
+  # process push stream
+end
+```
+
+The client can cancel any given push stream (via `.close`), or disable server push entirely by sending the appropriate settings frame:
+
+```ruby
+client.settings(settings_enable_push: 0)
+```
+### Specs
+
+To run specs:
+
+```ruby
+rake
+```
+
+### License
+
+(MIT License) - Copyright (c) 2013-2019 Ilya Grigorik ![GA](https://www.google-analytics.com/__utm.gif?utmac=UA-71196-9&utmhn=github.com&utmdt=HTTP2&utmp=/http-2/readme)
+(MIT License) - Copyright (c) 2019 Tiago Cardoso ![GA](https://www.google-analytics.com/__utm.gif?utmac=UA-71196-9&utmhn=github.com&utmdt=HTTP2&utmp=/http-2/readme)

data/vendor/bundle/ruby/4.0.0/gems/http-2-1.2.3/lib/http/2/base64.rb

@@ -0,0 +1,45 @@
+# frozen_string_literal: true
+
+if RUBY_VERSION < "3.3.0"
+  require "base64"
+elsif !defined?(Base64)
+  module HTTP2
+    # require "base64" will not be a default gem after ruby 3.4.0
+    module Base64
+      module_function
+
+      def encode64(bin)
+        [bin].pack("m")
+      end
+
+      def decode64(str)
+        str.unpack1("m")
+      end
+
+      def strict_encode64(bin)
+        [bin].pack("m0")
+      end
+
+      def strict_decode64(str)
+        str.unpack1("m0")
+      end
+
+      def urlsafe_encode64(bin, padding: true)
+        str = strict_encode64(bin)
+        str.chomp!("==") or str.chomp!("=") unless padding
+        str.tr!("+/", "-_")
+        str
+      end
+
+      def urlsafe_decode64(str)
+        if !str.end_with?("=") && str.length % 4 != 0
+          str = str.ljust((str.length + 3) & ~3, "=")
+          str.tr!("-_", "+/")
+        else
+          str = str.tr("-_", "+/")
+        end
+        strict_decode64(str)
+      end
+    end
+  end
+end

data/vendor/bundle/ruby/4.0.0/gems/http-2-1.2.3/lib/http/2/client.rb

@@ -0,0 +1,82 @@
+# frozen_string_literal: true
+
+module HTTP2
+  # HTTP 2.0 client connection class that implements appropriate header
+  # compression / decompression algorithms and stream management logic.
+  #
+  # Your code is responsible for driving the client object, which in turn
+  # performs all of the necessary HTTP 2.0 encoding / decoding, state
+  # management, and the rest. A simple example:
+  #
+  # @example
+  #     socket = YourTransport.new
+  #
+  #     conn = HTTP2::Client.new
+  #     conn.on(:frame) {|bytes| socket << bytes }
+  #
+  #     while bytes = socket.read
+  #       conn << bytes
+  #     end
+  #
+  class Client < Connection
+    # Initialize new HTTP 2.0 client object.
+    def initialize(settings = {})
+      @stream_id    = 1
+      @state        = :waiting_connection_preface
+
+      @local_role   = :client
+      @remote_role  = :server
+      @h2c_upgrade = nil
+
+      super
+    end
+
+    # Send an outgoing frame. Connection and stream flow control is managed
+    # by Connection class.
+    #
+    # @see Connection
+    # @param frame [Hash]
+    def send(frame)
+      send_connection_preface
+      super
+    end
+
+    def receive(frame)
+      send_connection_preface
+      super
+    end
+
+    # sends the preface and initializes the first stream in half-closed state
+    def upgrade
+      @h2c_upgrade = :start
+      raise ProtocolError unless @stream_id == 1
+
+      send_connection_preface
+      stream = new_stream(state: :half_closed_local)
+      @h2c_upgrade = :finished
+      stream
+    end
+
+    # Emit the connection preface if not yet
+    def send_connection_preface
+      return unless @state == :waiting_connection_preface
+
+      @state = :connected
+      emit(:frame, CONNECTION_PREFACE_MAGIC)
+
+      payload = @local_settings.connection_settings.reject { |k, v| v == SPEC_DEFAULT_CONNECTION_SETTINGS[k] }
+      settings(payload)
+    end
+
+    def self.settings_header(settings)
+      frame = Framer.new.generate(type: :settings, stream: 0, flags: 0, payload: settings)
+      Base64.urlsafe_encode64(frame[9..-1])
+    end
+
+    private
+
+    def verify_pseudo_headers(frame)
+      _verify_pseudo_headers(frame, RESPONSE_MANDATORY_HEADERS)
+    end
+  end
+end