Add agent context.

Author: ioquatix

context/design-overview.md

@@ -0,0 +1,209 @@
+# Design Overview
+
+This guide explains the high level design of `protocol-http` in the context of wider design patterns that can be used to implement HTTP clients and servers.
+
+## Request/Response Model
+
+The main model we support is the request/response model. A client sends a request to a server which return response. The protocol is responsible for serializing the request and response objects.
+
+```mermaid
+sequenceDiagram
+	participant CA as Application
+	participant Client
+	participant Server
+	participant SA as Application
+	CA->>+Client: Request
+	Client->>+Server: Request
+	Server->>+SA: Request
+	SA->>+Server: Response
+	Server->>+Client: Response
+	Client->>+CA: Response
+```
+
+We provide an interface for request and response objects. This provides performance, predictability and robustness. This model has proven itself over several years, handling a variety of different use cases.
+
+~~~ ruby
+class Request
+	attr :method
+	attr :target
+	attr :headers
+	attr :body
+end
+
+class Response
+	attr :status
+	attr :headers
+	attr :body
+end
+~~~
+
+One other advantage is that it's symmetrical between clients and servers with a clear mapping, i.e. the protocol is responsible for transiting requests from the client to the server, and responses from the server back to the client. This helps us separate and define request/response interfaces independently from protocol implementation.
+
+### Client Design
+
+A request/response model implies that you create a request and receive a response back. This maps to a normal function call where the request is the argument and the response is the returned value.
+
+~~~ ruby
+request = Request.new("GET", url)
+response = client.call(request)
+
+response.headers
+response.read
+~~~
+
+## Stream Model
+
+An alternative model is the stream model. This model is more suitable for WebSockets and other persistent bi-directional channels.
+
+```mermaid
+sequenceDiagram
+	participant CA as Application
+	participant Client
+	participant Server
+	participant SA as Application
+	CA->>+Client: Stream
+	Client->>+Server: Stream
+	Server->>+SA: Stream
+```
+
+The interfaces for streaming can be implemented a bit differently, since a response is not returned but rather assigned to the stream, and the streaming occurs in the same execution context as the client or server handling the request.
+
+~~~ ruby
+class Stream
+	# Request details.
+	attr :method
+	attr :target
+	attr :headers
+	
+	attr :response
+	
+	# Write the response and start streaming the output body.
+	def respond(status, headers)
+		response.status = status
+		response.headers = headers
+	end
+	
+	# Request body.
+	attr_accessor :input
+	
+	# Response body.
+	attr_accessor :output
+	
+	# Write to the response body.
+	def write(...)
+		@output.write(...)
+	end
+	
+	# Read from the request body.
+	def read
+		@input.read
+	end
+end
+
+class Response
+	def initialize(method, target)
+		@input = Body::Writable.new
+		@output = Body::Writable.new
+	end
+	
+	attr_accessor :status
+	attr_accessor :headers
+	
+	# Prepare a stream for making a request.
+	def request(method, target, headers)
+		# Create a request stream suitable for writing into the buffered response:
+		Stream.new(method, target, headers, self, @input, @output)
+	end
+	
+	# Write to the request body.
+	def write(...)
+		@input.write(...)
+	end
+	
+	# Read from the response body.
+	def read
+		@output.read
+	end
+end
+~~~
+
+### Client Design
+
+A stream model implies that you create a stream which contains both the request and response bodies. This maps to a normal function call where the argument is the stream and the returned value is ignored.
+
+~~~ ruby
+response = Response.new
+stream = response.request("GET", url)
+
+client.call(stream)
+
+response.headers
+response.read
+~~~
+
+## Differences
+
+The request/response model has a symmetrical design which naturally uses the return value for the result of executing the request. The result encapsulates the behaviour of how to read the response status, headers and body. Because of that, streaming input and output becomes a function of the result object itself. As in:
+
+~~~ ruby
+def call(request)
+	body = Body::Writable.new
+	
+	Fiber.schedule do
+		while chunk = request.input.read
+			body.write(chunk.reverse)
+		end
+	end
+	
+	return Response[200, headers, body]
+end
+
+input = Body::Writable.new
+response = call(... body ...)
+
+input.write("Hello World")
+input.close
+response.read -> "dlroW olleH"
+~~~
+
+The streaming model does not have the same symmetry, and instead opts for a uni-directional flow of information.
+
+~~~ruby
+def call(stream)
+	stream.respond(200, headers)
+	
+	Fiber.schedule do
+		while chunk = stream.read
+			stream.write(chunk.reverse)
+		end
+	end
+end
+
+input = Body::Writable.new
+response = Response.new(...input...)
+call(response.stream)
+
+input.write("Hello World")
+input.close
+response.read -> "dlroW olleH"
+~~~
+
+The value of this uni-directional flow is that it is natural for the stream to be taken out of the scope imposed by the nested `call(request)` model. However, the user must explicitly close the stream, since it's no longer scoped to the client and/or server.
+
+## Interim Response Handling
+
+Interim responses are responses that are sent before the final response. They are used for things like `103 Early Hints` and `100 Continue`. These responses are sent before the final response, and are used to signal to the client that the server is still processing the request.
+
+```ruby
+body = Body::Writable.new
+
+interim_response_callback = proc do |status, headers|
+	if status == 100
+		# Continue sending the request body.
+		body.write("Hello World")
+		body.close
+	end
+end
+
+response = client.post("/upload", {'expect' => '100-continue'}, body, interim_response: interim_response_callback)
+```

context/getting-started.md

@@ -0,0 +1,130 @@
+# Getting Started
+
+This guide explains how to use `protocol-http` for building abstract HTTP interfaces.
+
+## Installation
+
+Add the gem to your project:
+
+~~~ bash
+$ bundle add protocol-http
+~~~
+
+## Core Concepts
+
+`protocol-http` has several core concepts:
+
+  - A {ruby Protocol::HTTP::Request} instance which represents an abstract HTTP request. Specific versions of HTTP may subclass this to track additional state.
+  - A {ruby Protocol::HTTP::Response} instance which represents an abstract HTTP response. Specific versions of HTTP may subclass this to track additional state.
+  - A {ruby Protocol::HTTP::Middleware} interface for building HTTP applications.
+  - A {ruby Protocol::HTTP::Headers} interface for storing HTTP headers with semantics based on documented specifications (RFCs, etc).
+  - A set of {ruby Protocol::HTTP::Body} classes which handle the internal request and response bodies, including bi-directional streaming.
+
+## Integration
+
+This gem does not provide any specific client or server implementation, rather it's used by several other gems.
+
+  - [Protocol::HTTP1](https://github.com/socketry/protocol-http1) & [Protocol::HTTP2](https://github.com/socketry/protocol-http2) which provide client and server implementations.
+  - [Async::HTTP](https://github.com/socketry/async-http) which provides connection pooling and concurrency.
+
+## Usage
+
+### Request
+
+{ruby Protocol::HTTP::Request} represents an HTTP request which can be used both server and client-side.
+
+``` ruby
+require 'protocol/http/request'
+
+# Short form (recommended):
+request = Protocol::HTTP::Request["GET", "/index.html", {"accept" => "text/html"}]
+
+# Long form:
+headers = Protocol::HTTP::Headers[["accept", "text/html"]]
+request = Protocol::HTTP::Request.new("http", "example.com", "GET", "/index.html", "HTTP/1.1", headers)
+
+# Access request properties
+request.method           # => "GET"
+request.path             # => "/index.html"
+request.headers          # => Protocol::HTTP::Headers instance
+```
+
+### Response
+
+{ruby Protocol::HTTP::Response} represents an HTTP response which can be used both server and client-side.
+
+``` ruby
+require 'protocol/http/response'
+
+# Short form (recommended):
+response = Protocol::HTTP::Response[200, {"content-type" => "text/html"}, "Hello, World!"]
+
+# Long form:
+headers = Protocol::HTTP::Headers["content-type" => "text/html"]
+body = Protocol::HTTP::Body::Buffered.wrap("Hello, World!")
+response = Protocol::HTTP::Response.new("HTTP/1.1", 200, headers, body)
+
+# Access response properties
+response.status          # => 200
+response.headers         # => Protocol::HTTP::Headers instance
+response.body            # => Body instance
+
+# Status checking methods
+response.success?        # => true (200-299)
+response.ok?             # => true (200)
+response.redirection?    # => false (300-399)
+response.failure?        # => false (400-599)
+```
+
+### Headers
+
+{ruby Protocol::HTTP::Headers} provides semantically meaningful interpretation of header values and implements case-normalising keys.
+
+#### Basic Usage
+
+``` ruby
+require 'protocol/http/headers'
+
+headers = Protocol::HTTP::Headers.new
+
+# Assignment by title-case key:
+headers['Content-Type'] = "image/jpeg"
+
+# Lookup by lower-case (normalized) key:
+headers['content-type']
+# => "image/jpeg"
+```
+
+#### Semantic Processing
+
+Many headers receive special semantic processing, automatically splitting comma-separated values and providing structured access:
+
+``` ruby
+# Accept header with quality values:
+headers['Accept'] = 'text/html, application/json;q=0.8, */*;q=0.1'
+accept = headers['accept']
+# => ["text/html", "application/json;q=0.8", "*/*;q=0.1"]
+
+# Access parsed media ranges with quality factors:
+accept.media_ranges.each do |range|
+	puts "#{range.type}/#{range.subtype} (q=#{range.quality_factor})"
+end
+# text/html (q=1.0)
+# application/json (q=0.8)
+# */* (q=0.1)
+
+# Accept-Encoding automatically splits values:
+headers['Accept-Encoding'] = 'gzip, deflate, br;q=0.9'
+headers['accept-encoding']
+# => ["gzip", "deflate", "br;q=0.9"]
+
+# Cache-Control splits directives:
+headers['Cache-Control'] = 'max-age=3600, no-cache, must-revalidate'
+headers['cache-control']
+# => ["max-age=3600", "no-cache", "must-revalidate"]
+
+# Vary header normalizes field names to lowercase:
+headers['Vary'] = 'Accept-Encoding, User-Agent'
+headers['vary']
+# => ["accept-encoding", "user-agent"]
+```