HTTP/1.1, HTTP/2, and HTTP/3

radio_button_unchecked Chapter overview

HTTP is often presented through short GET and POST examples, but this view is insufficient for those operating enterprise gateways. In production, HTTP is a protocol with its own semantics, strict delimitation rules, negotiation mechanisms, cache, conditions, intermediaries and different transport mappings. A call that appears to be a single request can be received in HTTP/3 at the edge, converted to HTTP /2 up to the gateway, and forwarded in HTTP /1.1 to the backend. Each hop has its own connection, state, timeout, field compression and operational risk.

The HTTP /1.1, HTTP /2, and HTTP/3 versions do not represent three different APIs. They share methods, status codes, fields, and representation concepts defined by HTTP semantics, but they encode and transport these elements in different ways. HTTP /1.1 uses a textual syntax over a TCP stream ; HTTP /2 introduces binary frames and multiplexed streams over a connection; HTTP/3 takes HTTP semantics to QUIC , which works over UDP and integrates TLS 1.3 into the transport.

For an API Gateway engineer, the distinction between semantics and wire versioning is central. A 405 error is not a consequence of TCP or QUIC ; it indicates that the method is not allowed by the resource. An HTTP no response timeout points to another layer. A 502 may have been generated by the gateway after a failed connection to the upstream. Intermittent behavior in HTTP /2 may involve stream limits, flow window, drainage or an inappropriate translation to HTTP /1.1 in the next hop.

This chapter builds a complete mental model: first establishes the common semantics, then delves into the format and connections of HTTP /1.1, then explains the frame and stream architecture of HTTP /2, and finally introduces QUIC and HTTP/3 . The goal is not to memorize lists, but to understand which properties remain stable, which change between versions and what evidence should be collected at each point in an enterprise architecture.

Central principle

HTTP semantics pertain to the operation; the HTTP version and connection belong to each hop. A proxy finishes a message, applies rules, and creates a new message for the next destination.

Learning objectives

• Explain the semantic architecture of HTTP and separate meaning, representation , and transport mapping.
• Interpret method, request target, authority , fields, content , trailers and status codes.
• Distinguish security, idempotency and cacheability of the main methods.
• Design caching and revalidation using Cache-Control, Age, ETag , Last-Modified and conditional requests.
• Interpret HTTP /1.1 syntax, including CRLF, Content -Length, Transfer-Encoding, and contentless messages.
• Understand persistent connections, pipelining, keep-alive, timeouts and head-of-line blocking .
• Recognize risks of divergent parsing, request smuggling , response splitting and hop-by-hop fields.
• Explain frames, streams, multiplexing , flow control , GOAWAY and HPACK in HTTP /2.
• Understand ALPN , h2, h2c, connection coalescing and concurrency limits.
• Explain QUIC , TLS 1.3 integration, Connection IDs, migration, loss, and independent streams.
• Understand HTTP/3 frames, control streams, QPACK , Alt-Svc , and HTTPS/SVCB discovery.
• Compare HTTP /1.1, HTTP /2, and HTTP/3 on latency, observability, security, and operation.
• Apply the concepts to Axway API Gateway, Azure API Management and architectures with multiple proxies.
• Diagnose failures through traces, headers, logs, connection metrics and traffic captures.

Chapter structure

radio_button_uncheckedHTTP : application protocol and semantic architecture

RFC 9110 defines HTTP as a stateless application protocol for distributed systems and establishes concepts common to all versions. “Stateless” does not mean that applications cannot maintain session or business state. It means that the protocol does not require the server to preserve, between independent requests, the context necessary to interpret the next message. State can be represented in resources, databases, cookies, tokens, caches or sessions, but each request must carry enough information to be processed according to the contract.

The main semantic unit is a request or response message. A request expresses a method applied to a target, accompanied by fields and, optionally, content . A response communicates the result through a status code, fields, and possible content . HTTP does not determine that the content is JSON nor that the API is REST. The protocol can transport HTML, images, XML, Protobuf, files, events and other formats registered or agreed between the parties.

Semantics also defines properties that guide intermediaries. Caches need to know when a response can be reused; proxies need to differentiate fields destined for the next hop from end-to-end metadata; customers need to decide when an operation can be repeated after failure; gateways need to preserve authority , method and content without creating ambiguity. These properties are more important for interoperability than the textual appearance seen in an HTTP /1.1 example.

Reading for gateways

When a gateway receives HTTP /2 and calls a backend on HTTP /1.1, it does not “forward frames”. It decodes a message, executes policies, and generates another message compatible with the next protocol.

radio_button_unchecked Evolution: from minimal messages to multiplexed transport

HTTP /0.9 had an extremely simple form: a GET request followed by the path, and a response composed by the document. There were no status codes, fields, type negotiation, or persistent connection. This simplicity suited early Web documents, but did not offer suitable mechanisms for complex distributed applications. HTTP /1.0 introduced initial line versions, status codes, fields, and media types, allowing you to represent metadata and different content .

HTTP /1.1 consolidated persistent connections by default, the Host field, more complete caching, conditional requests, chunked transfers and framing rules. The protocol now supports multiple sites on the same IP address and reduces the cost of opening a connection per object. Still, the reliance on an ordered TCP stream and sequential format has created limits for pages and APIs with many concurrent operations.

HTTP /2 preserved the semantics and replaced the textual message format with binary frames associated with streams. This allowed us to interleave multiple exchanges on the same connection and compress repetitive fields with HPACK . HTTP/3 maintained the streams and frames model, but replaced TCP with QUIC . Thus, loss in one stream does not need to prevent the delivery of data available from other streams, and the cryptographic handshake becomes part of the transport establishment.

Semantic compatibility

A GET method is still GET in HTTP /1.1, HTTP /2, and HTTP/3 . What changes is how method, target, fields and content are represented and transported.

radio_button_unchecked Transaction model: request, response and self-describing messages

An HTTP transaction begins when a client sends a request to an origin or intermediary server. The request contains control information and metadata that allows you to determine the resource, operation and expected form of response. The server produces one or more informational responses and a final response. In HTTP /1.1, elements appear as lines and fields; in HTTP /2 and HTTP/3 , they are converted into pseudo-fields and frames.

The content of a message is conceptually different from its representation on the wire. Fields such as Content -Type and Content -Encoding describe the representation . Framing tells you how to locate content within the connection. In HTTP /1.1, Content -Length or chunked can delimit the body; In HTTP /2 and HTTP/3 , content is loaded in DATA frames and the end of the stream indicates completion. Confusing representation metadata with framing produces interoperability bugs and vulnerabilities.

Trailers are fields sent after the content . They can carry calculated metadata at the end of the transmission, such as integrity or status of protocols built on HTTP . Not all intermediaries preserve trailers, and the contract needs to consider this possibility. On gateways, turning streaming into full buffering can change latency, memory consumed, and the ability to deliver trailers to the client.

POST /v1/payments HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Content-Length: 42
{"amount":100.00,"currency":"BRL"}

radio_button_unchecked Identifiers, URI, authority and target of the request

A URI identifies a resource or reference used in the interaction. In common API usage, the URI includes scheme, authority , path, and query. At `https://api.example.com:443/v1/accounts/123? view=summary`, the scheme is HTTPS, the authority contains host and port, the path identifies a logical hierarchy and the query adds parameters. The fragment, when present in a URI, is processed by the client and is not sent in the HTTP request.

HTTP /1.1 uses different forms of request-target depending on the method and type of intermediary. The origin -form sends path and query; absolute-form is typical in forward proxies; authority -form is used by CONNECT; and the asterisk-form appears in OPTIONS `*`. The Host field is mandatory in HTTP /1.1 and informs the intended authority . In HTTP /2 and HTTP/3 , pseudo-fields such as `:scheme`, `: authority `, `:path` and `:method` represent these components.

Gateways must treat authority carefully because it participates in routing, certificate selection, policies, and protection against Host header attacks. A proxy can receive a public address and call a different internal host; This does not authorize indiscriminately substituting the meaning of the original authority . On some architectures, the backend needs to know the external host via `Forwarded` or equivalent fields, but these fields should only be trusted when entered by controlled intermediaries.

radio_button_unchecked Methods: intent, safety, and idempotency

The method expresses the intent of the request. GET requests the transfer of a representation ; HEAD requests the same metadata without response content ; POST asks the resource to process the content according to its semantics; PUT replaces or creates state in the target URI; DELETE requests the removal of the current association; OPTIONS describes communication options; CONNECT establishes a tunnel; TRACE runs a loopback diagnostic and is typically disabled in corporate environments.

A secure method is defined as essentially read-only: the client does not request a change to the server's state. This doesn't prevent logs, metrics, or operational billing, but it does mean that the intended effect is not a business change. Idempotence means that repeating the same intention multiple times should produce the same desired effect as a single execution. PUT and DELETE are semantically idempotent, although observable responses and side effects may vary .

The distinction is decisive for retries. A gateway can repeat a GET request after connection failure with less semantic risk. Retrying payment POST may duplicate the operation if the backend processed the content before the response was lost. Financial APIs often introduce an application idempotence key, persisting the result associated with a unique key. This strategy complements, but does not change, the semantics of the HTTP method.

Retry is not just a technical decision

Before configuring retries on the gateway, classify the operation, determine the point at which the upstream may have taken effect, and define how duplicates will be detected.

radio_button_unchecked Status codes and response authorship

The status code describes the result of the attempt to interpret and satisfy the request. 1xx responses are informative; 2xx indicate success; 3xx advise redirection or use of another representation ; 4xx indicate that the request cannot be met under the conditions presented; 5xx report server or intermediary failure. The class is relevant, but the specific code and associated fields provide the complete semantics.

In architectures with proxies, the final code can be created by any intermediary. A 401 can come from a gateway authentication policy without the backend being called. A 429 can represent the edge's rate limit. A 502 typically indicates that a gateway did not get a valid response from upstream; a 504 represents timeout acting as a gateway. Logs must record authorship, policy stage, and upstream status separately.

HTTP /1.1 reason phrases are informational and should not control logic. HTTP /2 and HTTP/3 carry the code in `:status` and do not carry reason phrase. Customers should make decisions based on the number and fields, not text like “OK” or “Unauthorized”. In APIs, error responses can add an issue format, correlation, and details, but the body does not replace status semantics.

radio_button_uncheckedHTTP fields: metadata, scope and normalization

HTTP fields are extensible name-value pairs. They carry information about control, representation , caching, authentication, negotiation and intermediaries. Names are case-insensitive, although values ​​may have specific rules. A field can allow a single occurrence, multiple occurrences, or a composable list. Implementations should not concatenate fields indiscriminately, especially `Set-Cookie`, whose semantics require specific treatment.

RFC 9110 distinguishes end-to-end fields from connection-related information. HTTP /1.1 uses the Connection field to declare field names that apply only to the next hop. Intermediaries must remove these fields before forwarding. HTTP /2 and HTTP/3 prohibit several connection-specific fields, as streams and frames replace mechanisms like `Transfer-Encoding: chunked`. Replicating HTTP /1.1 headers without understanding their scope can lead to protocol failures.

Normalization is necessary but dangerous. Gateways can change capitalization, order, combine lines, remove optional spaces, or reconstruct messages. Applications should not depend on the order of fields. On the other hand, HTTP signatures and authentication schemes can define explicit canonicalization. A gateway policy that modifies signed values ​​must be executed before signing or preserve exactly the covered components.

radio_button_unchecked Representations, media types and content negotiation

A resource is an abstraction; the representation is a sequence of bytes and metadata that describes a state of that resource. The same resource can be represented as JSON, XML, CSV, or image. ` Content -Type` reports the media type of the sent representation , while `Accept` expresses which types the client considers acceptable. Sending JSON without ` Content -Type: application/json` forces the receiver to infer or reject the content .

Content negotiation can occur proactively, using Accept, Accept-Encoding and Accept-Language fields, or reactively, when the server offers alternatives. The Vary field informs which dimensions of the request influenced the response selection and is essential for caches. If a response varies by `Accept-Encoding`, a cache should not hand over gzipped bytes to a client that does not accept them.

Content -Encoding describes transformations applied to the representation , such as gzip or br. It should not be confused with Transfer-Encoding, which in HTTP /1.1 participates in message framing . Gateways that decompress content for inspection need to decide whether to recompress, correct Content -Length, preserve ETag when semantically valid, and consider expansion limits to prevent decompression attacks.

GET /reports/2026 HTTP/1.1
Host: api.example.com
Accept: application/json, application/xml;q=0.8
Accept-Encoding: br, gzip
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
Vary: Accept, Accept-Encoding

radio_button_uncheckedHTTP cache: freshness, reuse and invalidation

HTTP caching is not just a browser optimization. CDNs, reverse proxies, and gateways can store responses and serve requests without calling the backend. RFC 9111 defines when a response can be stored, considered fresh, reused, or revalidated. Cache-Control carries directives such as max-age, no-cache, no-store, private, public and must-revalidate. `no-cache` does not mean “do not store”; means that the response needs to be validated before reuse, except for specific rules.

The age of a response considers the time since its generation and permanence in caches. The Age field informs estimated age. Shared caches must respect authorization and privacy policies. In banking APIs, storing custom responses without proper cache key can cause leakage between users. The key typically includes URI and dimensions indicated by Vary , but gateways can add specific rules depending on identity, tenant or product.

Invalidating cache is difficult because copies can exist at multiple levels. Strategies include short TTL, URI versioning, explicit purging, and revalidation. The choice needs to balance consistency, cost and availability. An unavailable backend can be protected by stored responses, but serving old information in financial operations may be unacceptable. Cache policy is a domain decision, not just a performance one.

radio_button_unchecked Conditional requests and concurrency control

Conditional requests allow you to perform an operation only if the resource state satisfies a condition. `If-None-Match` is used to revalidate cache or guarantee creation only when no current representation exists. `If-Match` requires that the current entity matches an ETag and is useful for avoiding lost updates. Date-based fields, such as If-Modified-Since and If-Unmodified-Since, have lower granularity and reliability than opaque validators.

ETag is an identifier of the selected representation . A strong ETag indicates byte-to-byte equivalence suitable for operations such as ranges; a weak one indicates sufficient semantic equivalence for certain cache uses. It does not need to be a cryptographic hash or reveal an internal version. Gateways that transform content can invalidate the backend's ETag , because the representation delivered to the client is no longer the same.

In optimistic control, the client reads a representation with ETag , changes it locally and sends PUT or PATCH with If-Match. If another actor modified the resource, the server responds 412 Precondition Failed. This avoids silently overwriting a concurrent update. The policy must be implemented in the component that controls the business state; a gateway can validate presence and format, but it does not know the current version of the resource on its own.

GET /accounts/123
<- ETag: "v17"
PATCH /accounts/123
If-Match: "v17"
Content-Type: application/merge-patch+json
{"nickname":"Reserva"}
<- 204 No Content   or   412 Precondition Failed

radio_button_uncheckedHTTP /1.1: textual syntax and byte stream

HTTP /1.1 represents messages as a start line, field sequence, empty line, and optional content . Lines are delimited by CRLF. A request starts with method, request-target and version; a response starts with version and status. Although tools display messages in a readable form, the implementation needs to handle octets, limits, spaces and prohibited characters according to the specification. Excessive tolerance for invalid messages is a recurring source of inconsistency between intermediaries.

The receiver needs to determine where each message ends in a persistent connection. TCP delivers a boundaryless message stream : a `recv()` can return part of a line, multiple lines, or data from consecutive messages. The HTTP parser accumulates bytes, recognizes the field section and applies framing rules. The connection cannot simply use “end of packet” as a boundary, as IP packets and TCP segments are inferior details that can be split or combined.

In APIs, size limits for initial row, fields, and content exist across clients, WAFs, gateways, and servers. A field accepted by the edge may be rejected by the gateway; a payload allowed by the gateway may exceed the backend. Settings need to be coordinated. Errors 400, 413, 414 and 431 help to differentiate between malformed requests, large content , long URIs and excessive fields.

HTTP-message = start-line CRLF
               *( field-line CRLF )
               CRLF
               [ message-body ]

radio_button_uncheckedFraming in HTTP /1.1: Content -Length, chunked and no body

Content -Length reports the length of the content in octets. When valid, the receiver reads exactly that amount after the empty line. `Transfer-Encoding: chunked` encodes content into blocks, each preceded by hexadecimal size, and ending with chunk zero and optional trailers. Chunked allows you to transmit without knowing the total size in advance, but it is a hop-by-hop mechanism and does not appear in HTTP /2 or HTTP/3 .

Not every answer has a body. Responses to HEAD do not include content , although the fields describe what a GET would have returned. Codes 1xx, 204 and 304 have specific rules without content . Successful responses to CONNECT change the connection to tunnel mode. In other cases, closing the connection may limit the response, but this prevents reuse and is less robust.

Multiple Content -Length with different values, improper combination of Content -Length and Transfer-Encoding or invalid chunked syntax need to be treated as an error. If a proxy and a backend choose different rules, they may disagree about where the request ends up. The result can range from connection corruption to request smuggling . The safe strategy is strict parsing and consistent normalization before forwarding.

radio_button_unchecked Persistent connections, reuse, pooling and timeouts

HTTP /1.1 uses persistent connections by default. After a response, client and server can reuse TCP/TLS for new requests, reducing handshakes and latency. Reuse is only safe when the previous message has been completely delimited and consumed. If a client abandons a body without reading it, the connection may become misaligned for the next transaction.

Gateways maintain pools of connections for backends. The pool separates the client connection from the upstream connection: hundreds of clients can share a pool of persistent connections, depending on competition and capacity. Relevant parameters include maximum per target, idle time, lifetime, connect timeout, read timeout, and validation before reuse. A load balancer can terminate idle connections before the gateway, causing resets by reusing apparently valid sockets.

Timeouts must form a coherent budget. The customer has to wait longer than the edge; the edge, more than the gateway; the gateway, enough time for the backend, but less than the total consumer limit. If everyone uses the same value, components can expire simultaneously and produce retry storms. Logs need to distinguish connection time, sending, waiting for the first byte and reading the content .

radio_button_unchecked Pipelining and head-of-line blocking in HTTP /1.1

Pipelining allows you to send multiple requests over a connection without waiting for each response. However, responses must be issued in the same order. If the first request takes time, ready responses from subsequent requests are delayed. This blocking is known as head-of-line at the HTTP /1.1 level. The complexity of retries, intermediary servers, and inconsistent implementations has limited the practical adoption of pipelining.

Customers have often worked around the problem by opening multiple parallel connections per source. This increases handshakes, port usage, queue congestion, and pressure on balancers. For APIs, multiple connections may distribute load differently than an HTTP /2 connection with many streams. Metrics based only on “active connections” fail to correctly represent competition when versions coexist.

HTTP /2 was designed to multiplex independent requests without imposing global ordering of responses. Still, all frames travel over a TCP stream , so a segment loss can delay the delivery of later bytes from all streams. HTTP/3 moves stream isolation to QUIC transport.

radio_button_unchecked Intermediaries, hop-by-hop fields and transformation

Proxy is an HTTP participant that receives one message and forwards another. It can select the next destination, apply authentication, transform content , cache, or record telemetry. A gateway acts as an intermediary with API-driven policies. The output message does not need to be byte-for-byte the same as the input, but it must preserve the defined semantics and meet security requirements.

Hop-by-hop fields belong to a single connection and should not be automatically forwarded. In HTTP /1.1, Connection declares options applicable to the hop; TE has restricted use; Transfer-Encoding and Upgrade describe the current connection. HTTP /2 and HTTP/3 remove or replace these concepts. A gateway translates framing , and should not send `Transfer-Encoding: chunked` in an HTTP /2 stream .

Transformations can change Content -Length, Content -Encoding, ETag , signature, cacheability and streaming. A policy that converts XML to JSON needs to define a new Content -Type and recalculate length. If the gateway buffers to validate schema, the first response may be slower and memory consumption may increase with payloads. The architecture must document which transformations are allowed and at which jump.

Operating rule

Capture the logical message before and after each relevant policy. Comparing only edge packets with backend logs ignores transformations introduced along the way.

radio_button_unchecked Divergent parsing and HTTP /1.1 message security

Request smuggling occurs when two participants interpret message boundaries differently. An attacker sends an ambiguous string; the first proxy considers a part as a body, while the second interprets remaining bytes as a new request. This can bypass controls, poison cache, mix responses between users or take unforeseen routes. Classical variations exploit conflicts between Content -Length and Transfer-Encoding, but the general problem is parsing disagreement.

Response splitting explores the insertion of line delimiters into values that end up embedded in headers, creating additional fields or responses. Implementations need to reject disallowed CR and LF. Inconsistent normalization of spaces, names, and characters can also create discrepancies. The principle is to accept only valid syntax, reject ambiguities and avoid forwarding partially interpreted messages.

HTTP /2 and HTTP/3 have binary framing , but can participate in attacks when an intermediary converts messages to HTTP /1.1 in an insecure way. An H2 request may contain metadata that, when serialized, creates ambiguities in the H1 backend. Therefore, security requires validation at the point of translation, not just at the edge. Recent specification updates also refine Upgrade requirements and anticipated data; Operators must keep track of errata and RFCs that update behavior.

Defense in depth

Use conforming parsers, remove ambiguous combinations, normalize once, keep frontend and backend updated, and explicitly test H2/H3 to H1 translations.

radio_button_uncheckedHTTP /2: binary framing layer

HTTP /2 is an optimized expression of HTTP semantics. After the connection is established, participants exchange binary frames with a fixed header that informs length, type, flags and stream ID. HEADERS frames carry blocks of compressed fields; DATA carries content ; SETTINGS negotiates parameters; WINDOW_UPDATE controls flow; RST_STREAM ends a stream ; GOAWAY initiates coordinated termination of the connection.

An HTTP message is mapped to a sequence of frames in a stream . The stream has an independent identifier and life cycle. An operation's request and response use the same stream . Frames from different streams can be interleaved, allowing concurrency without opening a TCP connection for each call. The receiver reconstructs each message using stream ID and flags such as END_HEADERS and END_STREAM.

The protocol starts with a connection preface and exchange of SETTINGS. Parameters include field table size, maximum number of simultaneous streams, initial window size, and maximum frame size. SETTINGS needs to be confirmed. Settings are directional: what an endpoint advertises limits the peer's behavior when sending to it.

radio_button_unchecked Streams, states, and shutdown

Streams can be idle, open, half-closed, reserved or closed, depending on frames sent and received. END_STREAM closes the sender direction, allowing the other direction to continue. RST_STREAM immediately terminates the stream and reports an error code. Stream errors don't have to bring down the entire connection; Connection errors require GOAWAY and shutdown.

GOAWAY contains the largest stream ID that may have been processed and an error code. The peer must not create new streams in the connection and can repeat stream operations above the limit, considering idempotence . In deployments and draining, gateways must issue GOAWAY and allow completion of accepted streams. Terminating TCP abruptly turns planned maintenance into indistinguishable network failures.

The number of competing streams is limited by SETTINGS_MAX_CONCURRENT_STREAMS and local resources. A client may maintain a connection, but be blocked waiting for credit to open a new stream . Metrics should show active, pending, and rejected streams, not just connections. A single client with HTTP /2 can generate high competition for a connection.

radio_button_uncheckedMultiplexing , flow control and memory pressure

Multiplexing allows frames to be interleaved, but does not eliminate the need for backpressure. HTTP /2 applies flow control to DATA at the connection and stream level. The receiver announces credit; as it consumes bytes, it sends WINDOW_UPDATE. If the application does not read a stream , its window may reset. If the connection window resets, all streams are prevented from sending DATA, even if some consumers are fast.

Flow control is not the same as TCP congestion control. The first protects receiver and application buffers; the second adapts sending to the network capacity. Both act simultaneously. Increasing windows can improve throughput on high bandwidth-delay product paths, but increases potential memory. Gateways need to limit streams, frames, fields and content to prevent a few clients from monopolizing resources.

The original HTTP /2 had a dependency and weighting mechanism for priorities that proved difficult to implement in an interoperable way. The current specification removes the old core model and allows for an extensible schema. Operators should not assume that client priority will be honored end-to-end, especially when there are proxies that reorder or convert protocols.

Classic symptom

A healthy TCP connection, responding HTTP /2 ping and some stopped streams may indicate an exhausted flow window or an application that has stopped consuming content .

radio_button_uncheckedHPACK : per-connection stateful field compression

APIs repeat fields such as method, schema, host, content type, and authentication. Sending them in full with each request increases overhead. HPACK compresses blocks of fields using a static table of common entries, a dynamic table constructed during connection, literal representations, and Huffman coding. A repeated entry can be referenced by index instead of relaying name and value.

The pivot table is directional and synchronized by the order of the blocks in the connection. The encoder decides which values ​​to enter; the decoder maintains the same sequence. Changing the table size or receiving an invalid index may generate a compression error and terminate the connection. Intermediaries end HPACK : the gateway decodes client fields and creates its own encoding when connecting to the backend.

Sensitive fields such as Authorization or cookies should not be indexed when doing so increases risk or retention. HPACK includes “never indexed” representation . Compression also interacts with side-channel attacks when secrets and controlled data share context. Field list size limits remain necessary, because a compact representation can expand to a lot of metadata.

radio_button_unchecked Negotiation: TLS, ALPN , h2 and h2c

On the secure web, HTTP /2 is typically negotiated over TLS over ALPN . The client advertises protocols, for example `h2` and ` http /1.1`; the server selects one and reports it in the handshake. This avoids sending a request in the wrong format. The certificate and name still need to be valid for the origin . Once h2 is selected, the client sends the preface and HTTP /2 frames.

HTTP /2 can also operate without TLS using the h2c identifier, with prior knowledge or Upgrade from HTTP /1.1, but this mode is less common on public traffic. In internal networks, some components use h2c for gRPC, while TLS terminates in sidecar or gateway. This decision reduces encryption by one leap and needs to be evaluated according to trust, compliance and observability.

Connection coalescing allows an HTTP /2 connection to be reused for multiple sources when resolution, certificate, and authority requirements are met. This improves efficiency, but can surprise connection-based balancing. Gateways and CDNs need to prevent unauthorized authority from being served on the connection. Logical origin remains determined by semantics, not just the connected IP address.

radio_button_uncheckedHTTP/3 : HTTP semantics over QUIC

HTTP/3 maps HTTP semantics to QUIC . QUIC is a connection-oriented transport encapsulated in UDP, with streams, flow control , loss detection, congestion control, security and path migration. TLS 1.3 is integrated into the handshake; There is no HTTP/3 mode without cryptographic protection as per the specification. The application sees individually ordered, reliable streams, not raw UDP datagrams.

Just like HTTP /2, HTTP/3 uses HEADERS and DATA frames, but the frames travel in QUIC streams. Each request uses a bidirectional stream initiated by the client. Unidirectional streams carry control and QPACK . Functions that QUIC already offers, such as stream ID and flow control , are not duplicated by the HTTP layer. Therefore, some HTTP /2 frames and mechanisms disappear or change.

Using UDP does not mean that HTTP/3 is unreliable. QUIC implements commit, retransmission, and stream ordering. The difference is that these functions are in user space, integrated with cryptography and capable of evolving without depending on the operating system's TCP implementation. Firewalls and middleboxes that block UDP can prevent QUIC , requiring a fallback to HTTP /2 or HTTP /1.1.

Mental model

HTTP/3 is not “ HTTP /2 over UDP”. It reuses ideas from streams and frames, but delegates to QUIC properties that in HTTP /2 depend on separate TCP and TLS.

radio_button_uncheckedQUIC handshake, TLS 1.3 and 0-RTT

The QUIC handshake negotiates transport parameters and runs TLS 1.3. On a new connection, the client can send an Initial packet containing ClientHello data; the server responds and the keys evolve through encryption levels. Under normal conditions, application data can be sent with a low number of round trips. QUIC protects almost all control content , reducing the passive visibility available to middleboxes.

On resumed connections, 0-RTT may allow the client to send application data before fully acknowledging the new handshake. This data does not have the same replay protection as 1-RTT data. Servers should accept 0-RTT only for replay-safe operations or apply anti-replay and idempotence mechanisms. A financial POST should not be considered secure just because it uses TLS.

QUIC applies amplification protection before validating the client address: the server limits bytes sent relative to those received. Retry tokens can help validate origin and control abuse, at the cost of additional round tripping. Gateways at the edge need to scale handshake state, thresholds, and DoS protection without treating all UDP as sessionless traffic.

radio_button_uncheckedQUIC streams and head-of-line elimination between streams

Each QUIC stream offers reliable, orderly delivery within the stream itself. Packets can carry frames from multiple streams. If a packet with data from stream B is lost, the receiver can continue delivering complete data from streams A and C. Only the missing point from B prevents orderly advancement of that stream . This eliminates the traversal blocking caused by single- stream TCP over HTTP /2.

Improvement does not eliminate every blockage. A stream remains ordered; Losing early bytes prevents delivering later bytes from the same stream . Connection flow control can also block all streams if the receiver does not grant credit. QPACK dependencies can suspend decoding of a block of fields. Therefore, metrics and traces need to distinguish packet loss, stream blocked by data, stream blocked by fields and connection window.

QUIC numbers data and acknowledges packets, but retransmits information in new packets, not “the same packet”. Packet numbers are never reused in the same space. Loss detection and congestion control were specified in associated documents. Implementation in user space allows evolution, but also requires specific observability of the library or proxy that terminates QUIC .

radio_button_unchecked Connection IDs, NAT rebinding and path migration

TCP identifies a connection by its set of addresses and ports. If a mobile device switches from Wi-Fi to cellular, the tuple changes and the connection is typically lost. QUIC uses Connection IDs chosen by endpoints, allowing you to associate packets from a new path to the existing connection. The new path is validated with challenges before being used fully.

Connection IDs also allow balancers to forward packets without relying exclusively on the tuple. The design needs to consider privacy and prevent a stable identifier from allowing cross-network tracking; Endpoints can provide multiple IDs and retire them. QUIC -aware gateways and load balancers need to coordinate routing, retry/reset keys, and affinity.

Migration is not a guarantee of continuity in any environment. Policies can disable it; firewalls can block the new path; the server may require validation; MTU and RTT changes alter performance. Logs must record migration and path validation to differentiate legitimate network exchange from instability or attack.

radio_button_unchecked Frames and control streams in HTTP/3

An HTTP/3 connection has one control stream per endpoint. It sends SETTINGS, GOAWAY and other control frames. Prematurely closing the control stream is a connection error. Requests use bidirectional streams from the client; each carries HEADERS, DATA, and trailers as permitted. Frames of a message cannot appear in any arbitrary order.

As QUIC provides flow control and stream reset, HTTP/3 uses transport mechanisms for part of the lifecycle. Errors have HTTP/3 and QUIC codes. A cancellation may involve resetting the shipment and requesting to stop the opposite direction. Observability must associate QUIC stream , HTTP request and application correlation, as a single connection ID can carry many operations.

HTTP/3 removes features from HTTP /2 that depended on the TCP stream , but preserves the concept of drainage. GOAWAY limits new accepted request streams. In deploy, the edge must announce closure, maintain the connection while allowed operations end, and direct new calls to another connection. Closing UDP state abruptly causes loss of all active operations.

radio_button_uncheckedQPACK : field compression suitable for QUIC streams

HPACK depends on the unique TCP connection order to synchronize the pivot table. In QUIC , streams can be delivered independently; a missed table update should not unnecessarily block all streams. QPACK uses unidirectional encoder and decoder streams to transmit instructions and acknowledgments, allowing blocks of fields in request streams to make controlled references.

A block can depend on inputs not yet received and block until instructions arrive. The decoder announces limits for the number of blocked streams, and the encoder chooses between better compression and risk of blocking. Literal representations and static table allow you to avoid dependencies. As with HPACK , sensitive values ​​can be marked for non-indexing.

Gateways terminate QPACK and create new context on next connection. A QPACK failure is a connection error and can affect many requests. Monitoring only HTTP status does not reveal this class of failure, because the message may not be reconstructed. HTTP/3 terminator logs must expose decompression error codes and blocked streams.

radio_button_uncheckedHTTP/3 , Alt-Svc , HTTPS/SVCB discovery and fallback

A client needs to know which origin offers HTTP/3 and on which endpoint. RFC 9114 defines advertisement by Alternative Services: an HTTP /1.1 or HTTP /2 response may include ` Alt-Svc : h3=":443"`. The client stores the alternative for a limited time and tries QUIC . DNS can also provide HTTPS/SVCB records with protocol and endpoint parameters. Support varies between customers and infrastructure.

The logical source remains the same, even if the alternative service is on a different host or port. The client needs to validate the authority and certificate according to the rules. Alt-Svc is not application redirection and does not change the displayed URI. If the QUIC attempt fails, clients typically continue or fall back to HTTP /2/1.1, but timing and failure cache details are implementation dependent.

When troubleshooting, confirm that the client received an announcement, that UDP was attempted, that ALPN h3 was negotiated and that fallback occurred. A capture of just TCP traffic can show the call working and hide failed QUIC attempts. Blocking UDP/443 can increase initial latency even when fallback maintains availability. Incorrect HTTPS/SVCB records may direct modern clients to a different endpoint than the one used by legacy clients.

HTTP/1.1 200 OK
Alt-Svc: h3=":443"; ma=86400
# The client can attempt a QUIC connection to the same origin on port 443.

radio_button_unchecked Architectural comparison between HTTP /1.1, HTTP /2 and HTTP/3

Choosing a version is not just looking for “the newest one”. HTTP /1.1 has broad compatibility and simple observability, but requires more connections for concurrency and suffers from sequential blocking. HTTP /2 reduces overhead and allows many streams in one connection, being essential for gRPC, but it concentrates operations on a TCP and requires stream and flow metrics. HTTP/3 improves behavior under loss and mobility, but depends on UDP, ends encryption in the component that needs to interpret HTTP , and changes networking practices.

Earnings depend on the profile. In a stable network and low latency, a small API may show modest difference. In lossy mobile connections, HTTP/3 can reduce impact between streams and preserve connection during path change. In an enterprise architecture with many intermediaries, the end-to-end benefit may be reduced if the edge receives H3 but the rest use H1.1 with saturated pools.

Protocols also affect capacity. Ten thousand requests can use thousands of H1 connections, hundreds of H2 or H3 connections, depending on concurrency and limits. Balancing by connections is less representative in multiplexing . A single client can concentrate streams on one instance. Algorithms, limits and observability need to evolve with the protocol.

radio_button_unchecked API Gateways and per-hop protocol translation

In an enterprise chain, each component can negotiate its own version. A client uses HTTP/3 with a CDN; CDN uses HTTP /2 with API Gateway; the gateway uses HTTP /1.1 with the backend. Semantics need to be preserved, but framing , compression, multiplexing and connection are reconstructed. There is no H3 stream “traversing” a gateway that ends HTTP .

Translation changes behavior. Many multiplexed requests from an H2 connection may require multiple H1 connections to the backend or be serialized according to pooling. Trailers may be lost if the next protocol or product does not preserve them. A stream reset can turn into a socket cancellation, while the backend has already processed the operation. GOAWAY on one side has no direct correspondence in an independent connection on the other side.

Policies must be semantic. Rate limiting per connection is inappropriate when a connection contains hundreds of streams. Payload limits need to consider uncompressed size. Cache must use correct authority and Vary . Observability needs to record inbound version, outbound version, reuse, stream ID when available, retry attempt and status created by the gateway.

Architecture question

What is the version negotiated in each real connection: client-edge, edge-gateway, gateway-mesh and mesh-backend? The answer “the API uses HTTP /2” is usually incomplete.

radio_button_unchecked Using Axway API Gateway

Axway API Gateway uses HTTP services to receive traffic and configurations from remote hosts for outgoing connections. In a real design, listener, interface, TLS, policy, routing and destination configurations participate in different hops. The investigation must separate the version and fields received by the listener from what is produced when connecting to the remote host. The documentation and installed version need to be consulted, as capabilities and standards may vary by release.

When forwarding to a backend, persistent connection and pooling influence latency, distribution and socket consumption. Legacy configurations can use conservative HTTP behaviors, and teams must explicitly validate the desired outbound version. Transformations and filters can change content , fields, and streaming. Transaction Access Logs and policy tracing should record final status, connection time, response time, and routing error.

A common scenario is that the client observes HTTP /2 at the edge, but the backend records HTTP /1.0 or HTTP /1.1. This is not necessarily an error; it could be a decision or default of the outbound hop. The risk arises when the application depends on trailers, streaming or competition that does not survive translation. Tests must cover the actual protocol, not just the public endpoint.

radio_button_unchecked Application in Azure API Management

In Azure API Management, the gateway receives calls, applies policies, and routes them to backends. Support for HTTP /2 inbound, outbound and gRPC depends on gateway type and generation, tier and configuration. The `forward-request` policy has an HTTP version attribute for supported scenarios. As the platform evolves, the official documentation must be treated as the source of truth for the instance used.

The inbound version does not imply an outbound version. Current documentation describes behaviors where certain generations support HTTP /2 and can downgrade forwarding, while others allow you to configure HTTP /2 for the backend. This affects gRPC, trailers, and streaming. Tests should record `context`/traces, backend diagnostics, and instance metrics to confirm the effective path.

Policies such as rewrite-uri, set-header, set-body, cache, retry and rate-limit operate on the logical message and can change observed characteristics. Retry needs to consider idempotence . Set-body generally implies access to content and may require buffering. Cache must respect identity and Vary . When combining Application Gateway, Front Door, APIM and backend, each service terminates its own connection and may have a different timeout.

radio_button_unchecked Observability: what to measure in each version

Common metrics include request rate, status, latency, bytes, and errors. For HTTP /1.1, add open connections, new connections per second, reuse, pool wait, and resets. For HTTP /2, measure active streams per connection, concurrency threshold, RST_STREAM, GOAWAY , stream window, and compression errors. For HTTP/3 , include QUIC retries, success/fallback, handshake, loss, RTT, migration, blocked streams, and QPACK errors.

Latency must be decomposed. DNS, connection, TLS/ QUIC , policy time, pool wait, time to first upstream byte and content transfer answer different questions. A high “total” metric does not identify cause. Distributed tracing starts when there is an HTTP message; Previous failures may require network logs and terminators. The gateway must reliably create or propagate correlation identifiers.

Traffic captures remain useful, but encryption limits content . In TLS over TCP, the terminator can provide key logging in a controlled laboratory. QUIC encrypts more control elements, so qlog and library metrics are valuable. In banking production, collection must respect sensitive data: do not record tokens, cookies, PAN, payloads or complete headers without masking and legal basis.

radio_button_unchecked End-to-end HTTP troubleshooting method

The first step is to determine whether there was a valid HTTP response. DNS, TCP, UDP, TLS, or QUIC errors may occur before any status. Tools sometimes convert failures into generic messages, but the gateway cannot have produced 504 if the call didn't even reach it. Identify the last component that has evidence of the attempt and the first that does not.

When status exists, determine authorship. Compare public status, upstream status, internal error and executed policy. A 503 from the backend can be preserved; another 503 might be created by the gateway because no healthy endpoints were available. Headers like Server are not enough proof as they can be removed or faked. Use correlation and timestamps between controlled logs.

Then record version and connection on each hop. Confirm ALPN , outbound protocol, reuse, stream reset, GOAWAY , retry and timeout. Compare method, authority , path, relevant fields, and length before and after the gateway. For intermittent failures, look for patterns by connection, instance, stream , payload size, version, network, and deploy time.

radio_button_unchecked Case Study 1: Duplicate POST after 504

A client sends POST to create a transfer. The gateway forwards it to the backend, which confirms the transaction at the bank, but takes a while to generate the response. The gateway timeout expires and returns 504. The client interprets it as failure and repeats the call. Since POST is not idempotent by definition and there is no deduplication key, the backend creates a second transfer.

The problem is not solved just by increasing timeout. The architecture must define idempotence semantics: client sends unique key; gateway preserves; backend records key and result atomically. On repeat, returns the previous result. The gateway can use retry only for failures clearly prior to submission or in classified operations. Logs need to show request ID, idempotency key, attempt and backend result.

Learning

Timeout means no confirmation to the observer, not proof of no effect on the remote system.

radio_button_unchecked Case Study 2: Public HTTP /2 and HTTP /1.1 backend saturation

An edge receives thousands of HTTP /2 streams in a few connections and forwards them to the gateway. The gateway calls an HTTP /1.1 backend with a pool of 100 connections. During peak, streams enter quickly but wait for upstream connection. Inbound TCP metrics appear stable because there are few H2 connections; queue and latency grow in the outbound pool.

The solution requires measuring competition by stream and wait pool, applying admission limits, adjusting backend capacity and considering HTTP /2 outbound when supported. Increasing pool without evaluating resources can shift overload to the service. Rate limiting per connection would be ineffective, as an H2 connection concentrates many streams. The goal is to align logical competition with actual upstream capacity.

Learning

In multiplexed protocols, connection is no longer a good approximation for the number of simultaneous operations.

radio_button_unchecked Case Study 3: HTTP/3 advertised but UDP blocked

A CDN starts announcing ` Alt-Svc : h3`. Modern clients try QUIC on UDP/443, but a corporate network blocks UDP. After a delay, the client falls back to HTTP /2 and the API works. Users report slowness only on first access; tests that force HTTP /2 do not reproduce. API logs show normal requests, because the attempt fails before the HTTP message arrives.

The investigation needs to look at DNS, Alt-Svc , UDP packets, and fallback timing. The fix may involve enabling QUIC , removing advertising for specific networks when possible, or accepting fallback with monitoring. It should not be concluded that HTTP/3 caused an application error. The problem lies in the discovery and establishment of the transport, prior to the HTTP transaction observed by the gateway.

Learning

Fallback availability can hide a path failure and add invisible latency in application logs.

radio_button_unchecked Case study 4: H2 to H1 translation creates insecure framing

A proxy accepts HTTP /2 and converts pseudo-fields and DATA to HTTP /1.1. A malformed combination passes H2 validation, but generates two incompatible length signals in H1. The backend interprets the message differently and controlled bytes make up the next request in the persistent connection. The vulnerability only appears when the path includes the specific translation.

Mitigation requires validating the logical message before serializing H1, emitting exactly one framing mechanism, rejecting prohibited fields, updating intermediaries, and testing smuggling variations. Disabling reuse can reduce impact, but does not replace correction. WAF based only on H2 input text may not see the message produced to the backend.

Learning

The point of greatest risk is often the boundary between two parsers or versions, not an isolated parser.

radio_button_unchecked Practical reading and diagnostic labs

Lab 1 - Compare HTTP /1.1 and HTTP /2 with cURL

Use a lab endpoint that supports both versions. Run calls forcing HTTP /1.1 and HTTP /2 and enable verbose output. Note resolution, connection, TLS, ALPN , request line displayed, reuse and timing. Repeat multiple calls in the same process to check reuse. Do not use productive endpoints or real tokens.

curl -v --http1.1 https://SEU-ENDPOINT-DE-LAB/status
curl -v --http2   https://SEU-ENDPOINT-DE-LAB/status
# Also record times:
curl -sS -o /dev/null -w "connect=%{time_connect} tls=%{time_appconnect} ttfb=%
{time_starttransfer} total=%{time_total}\n" https://SEU-ENDPOINT-DE-LAB/status

Lab 2 - Inspect ALPN with OpenSSL

Connect to a lab server and advertise h2 and HTTP /1.1. Confirm the selected protocol. Then force just http /1.1 and compare. The goal is to realize that ALPN occurs in the TLS handshake before HTTP messages. In proxy environments, run from different network points to identify different endpoints.

openssl s_client -connect SEU-ENDPOINT-DE-LAB:443 -servername SEU-ENDPOINT-DE-LAB -alpn
"h2,http/1.1"
# Search for: ALPN protocol: h2

Lab 3 - Cache and revalidation

Create a lab service that returns ETag and Cache-Control. Do a GET, store the ETag and send If-None-Match. Confirm 304 no content . Modify the resource and repeat. Add a controlled cache proxy and watch Age and Vary . Document how authentication changes the possibility of shared cache .

curl -i https://SEU-ENDPOINT-DE-LAB/resource
curl -i -H "If-None-Match: \"ETAG-RECEBIDA\"" https://SEU-ENDPOINT-DE-LAB/resource

Lab 4 - Framing HTTP /1.1 in an isolated environment

On a local server created for study, send messages with correct Content -Length and valid chunked. Notice how the server reads the body. Then test invalid inputs only in an authorized laboratory and confirm that they are rejected, without trying to exploit third-party systems. The goal is to understand parsing and validation, not to execute attacks.

printf "POST /echo HTTP/1.1\r\nHost: localhost\r\nContent-Length: 5\r\n\r\nhello" | nc
127.0.0.1 8080

Lab 5 - Observe HTTP/3 and fallback

Use a lab tool and endpoint with known HTTP/3 support. Record QUIC attempt, final protocol, and fallback when UDP is blocked in a test environment. Compare time to first byte. Do not change corporate firewalls without authorization. On clients that support qlog, generate a local trace and view handshake and streams.

curl -v --http3 https://SEU-ENDPOINT-DE-LAB/status
curl -v --http3-only https://SEU-ENDPOINT-DE-LAB/status
# The availability of options depends on the compilation of cURL and the QUIC library.

Lab 6 - Mapping versions by hop in the gateway

Publish a lab API that returns protocol, host, and correlation headers observed by the backend. Call the public endpoint in different versions and compare listener logs, policy traces, and backend output. Draw each independent connection and note TLS, ALPN , version, pool, timeout and transformation. This map is more useful than declaring a single “API version”.

1. Register client-edge protocol.
2. Register edge-gateway protocol.
3. Register gateway-backend protocol.
4. Compare Host/: authority and Forwarded fields.
5. Execute call with large content and observe buffering.
6. Run controlled deploy and observe draining/ GOAWAY or resets.

radio_button_uncheckedHTTP Architecture Checklist for Enterprise APIs

radio_button_unchecked Chapter Summary

HTTP provides stable semantics for interaction between clients, servers and intermediaries. Methods express intention; statuses communicate results; fields describe control and representation ; cache and conditions allow for reuse and concurrency. These concepts are independent of JSON, REST, or the transport version.

HTTP /1.1 encodes textual messages into a TCP stream and requires strict framing rules. Persistent connections save handshakes, but pooling, timeouts, and divergent parsing create risks. HTTP /2 introduces frames, streams, multiplexing , flow control and HPACK , reducing overhead and head-of-line at the HTTP level, although TCP loss still affects all streams.

HTTP/3 uses QUIC over UDP, integrates TLS 1.3, isolates loss per stream , supports Connection IDs and uses QPACK . Discovery can occur via Alt-Svc and HTTPS/SVCB records, with fallback to previous versions. In gateways, each hop negotiates its own version; the professional needs to observe the logical message and connection of each segment.

Reliable troubleshooting starts by classifying whether the failure occurred before or after there was an HTTP response, identifying who created the status and mapping versions, timeouts, pools, streams and transformations. The architecture must protect semantics, idempotence , and security during translations between protocols.

radio_button_unchecked Review exercises

1. Explain the difference between HTTP semantics and specific version mapping.
2. Why doesn't stateless mean that an application cannot maintain a session?
3. Differentiate resource, representation , content and framing .

1. Which components of a URI participate in an HTTP request and which are not sent?
2. Differentiate secure method from idempotent method and give examples.
3. Why repeating POST after timeout can produce duplicity even when the client received 504?
4. Who can create a 502 on a chain with multiple proxies?
5. Why should reason phrase not be used in client logic?
6. Differentiate Content -Type, Content -Encoding and Transfer-Encoding.
7. Explain why Vary is necessary in caching content negotiation .
8. What does `Cache-Control: no-cache` mean?
9. How do ETag and If-Match help avoid lost update?
10. Why doesn't TCP preserve HTTP message boundaries?
11. What risks exist when Content -Length and Transfer-Encoding are interpreted differently?
12. Why can a persistent connection only be reused after completely consuming the previous message?
13. Describe head-of-line in HTTP /1 pipelining.
15. How does HTTP /2 map a request to frames and streams?
16. Differentiate between HTTP /2 flow control and TCP congestion control.
17. What is the role of SETTINGS_MAX_CONCURRENT_STREAMS?
18. How does GOAWAY help with deployments and draining?
19. How does HPACK reduce overhead and why does it create per-connection state?
20. What is the role of ALPN in HTTP /2 negotiation?
21. Why is HTTP /2 still subject to TCP head-of-line?
22. Why is stating that HTTP/3 is “UDP untrusted” wrong?
23. How does QUIC enable path migration?
24. What is the risk of 0-RTT for effect trades?
25. How does QPACK differ conceptually from HPACK ?
26. How can Alt-Svc advertise HTTP/3 without changing the logical origin ?
27. Why can an API use HTTP/3 publicly and HTTP /1.1 in the backend?
28. What additional metrics are needed in HTTP /2 and HTTP/3 ?
29. Propose a timeout budget for client, edge, gateway and backend.
30. Design a secure retry strategy for payment GET and POST.
31. Explain how an H2 to H1 translation can create a risk of request smuggling .
32. Describe the evidence needed to prove which version was used in each jump.

radio_button_unchecked Architectural Discussion Questions

• In an organization with thousands of APIs, what criteria justify enabling HTTP /2 or HTTP/3 at the edge and backend?
• How should balancers distribute load when few connections carry many streams?
• Which fields should be removed or rebuilt in a chain with CDN, WAF, gateway and service mesh?
• How to guarantee idempotence of financial operations when timeouts and retries can occur in several components?
• What level of QUIC observability is acceptable in a regulated environment without exposing sensitive data?
• When is buffering at the gateway necessary and when does it destroy streaming benefits?
• How to test parsing and protocol translation security on an automated conveyor belt?

radio_button_unchecked Glossary

radio_button_unchecked Official references and recommended reading

The references below prioritize specifications and official documentation. RFCs must be consulted with their errata and any documents that update them. Product documentation must be validated for the version, tier and gateway used in the environment.

1. RFC 9110 - HTTP Semantics - https://www.rfc-editor.org/rfc/rfc9110.html
2. RFC 9111 - HTTP Caching - https://www.rfc-editor.org/rfc/rfc9111.html
3. RFC 9112 - HTTP /1.1 - https://www.rfc-editor.org/rfc/rfc9112.html
4. RFC 9113 - HTTP /2 - https://www.rfc-editor.org/rfc/rfc9113.html
5. RFC 9114 - HTTP/3 - https://www.rfc-editor.org/rfc/rfc9114.html
6. RFC 7541 - HPACK : Header Compression for HTTP /2 - https://www.rfc-editor.org/rfc/rfc7541.html
7. RFC 9204 - QPACK : Field Compression for HTTP/3 - https://www.rfc-editor.org/rfc/rfc9204.html
8. RFC 9000 - QUIC : A UDP-Based Multiplexed and Secure Transport - https://www.rfc-editor.org/rfc/rfc9000.html
9. RFC 9001 - Using TLS to Secure QUIC - https://www.rfc-editor.org/rfc/rfc9001.html
10. RFC 9002 - QUIC Loss Detection and Congestion Control - https://www.rfc-editor.org/rfc/rfc9002.html
11. RFC 7838 - HTTP Alternative Services - https://www.rfc-editor.org/rfc/rfc7838.html
12. RFC 9460 - Service Binding and HTTPS DNS Resource Records - https://www.rfc-editor.org/rfc/rfc9460.html
13. RFC 9651 - Structured Field Values for HTTP - https://www.rfc-editor.org/rfc/rfc9651.html
14. RFC 7301 - TLS Application-Layer Protocol Negotiation - https://www.rfc-editor.org/rfc/rfc7301.html
15. RFC 9308 - Applicability of the QUIC Transport Protocol - https://www.rfc-editor.org/rfc/rfc9308.html
16. RFC 9312 - Manageability of the QUIC Transport Protocol - https://www.rfc-editor.org/rfc/rfc9312.html
17. IANA HTTP Field Name Registry - https://www.iana.org/assignments/ http -fields/ http -fields.xhtml
18. IANA HTTP Status Code Registry - https://www.iana.org/assignments/ http -status-codes/ http -status-codes.xhtml
19. Axway - Configure HTTP services - https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_policydev/apigw_gw_instances/general_services/index.html
20. Axway - Configure remote host settings - https://docs.axway.com/bundle/axway-open-docs/page/docs/apim_policydev/apigw_gw_instances/general_remote_hosts/index.html
21. Microsoft - API gateway in Azure API Management - https://learn.microsoft.com/en-us/azure/api-management/api-management-gateways-overview
22. Microsoft - forward-request policy - https://learn.microsoft.com/en-us/azure/api-management/forward-request-policy
23. Microsoft - Manage protocols and ciphers in API Management - https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-manage-protocols-ciphers

Suggested reading order

1. Read the introductory sections and terminology of RFC 9110 before studying specific versions.
2. Study RFC 9112 with a focus on message framing , connection and parsing security.
3. Read the overview, frames, streams, flow control and errors of RFC 9113; consult HPACK in parallel.
4. Study QUIC in the connection, streams, flow control and migration sections of RFC 9000, followed by TLS integration in RFC 9001.
5. Read RFC 9114 and QPACK , relating what was delegated to QUIC .
6. Consult Alt-Svc and HTTPS/SVCB to understand discovery and fallback.
7. Finally, map the capabilities and limitations of the version of Axway and Azure APIM used in the work.

Closing

Mastering HTTP means mastering the boundary between business intent and transport. The next chapter will delve deeper into HTTPS and TLS, explaining how identity, confidentiality, and integrity protect each of these connections.