]> Aalyria Technologies

rtaylor@aalyria.com

Internet Delay/Disruption Tolerant Networking DTN BPv7 Bundle Protocol HTTP Binary HTTP Caching This document specifies a mechanism for carrying HTTP over Bundle Protocol Version 7 (BPv7) networks. Each HTTP request and each HTTP response travels as a single bundle, encoded as a Binary HTTP message inside a small CBOR envelope that correlates responses with requests. Because every bundle carries a complete, self-contained message, the mechanism needs none of the reliable, ordered, connection-oriented transport services that HTTP otherwise relies on, and it tolerates the delay, disruption, reordering, and duplication of a Delay-Tolerant Network. HTTP semantics are unchanged; only the transport beneath them is replaced. The mechanism enables HTTP application-layer gateways at the edges of a bundle network, through which unmodified HTTP clients and origin servers communicate across it, and also lets BP-native applications act as HTTP clients or origin servers directly. The document describes how gateways use HTTP caching to remain useful when round trips are long or intermittent, and it requests a well-known ipn service number and a registry for envelope options. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies a mechanism for carrying HTTP over networks that use Bundle Protocol Version 7 (BPv7) : HTTP over BP. HTTP semantics are unchanged; only the transport beneath them is replaced. Each HTTP request and each HTTP response is encoded as a Binary HTTP message and carried as the application data unit (ADU) of a single bundle, inside a small CBOR envelope that correlates each response with its request (). No connection, stream, or sequence state spans the bundle network. Every bundle can be interpreted on its own, so reordering, duplication, and arbitrary delay need no recovery mechanism, and the loss of a bundle loses one exchange, never a connection. Any BP node can use HTTP over BP to send HTTP requests or to answer them, whether or not that node also speaks HTTP over IP. describes the uses of the mechanism and how it compares with the alternatives.

Scope This document specifies:

• the format of the ADUs that carry HTTP messages ();
• the procedures by which a requester and a responder exchange them (), including responses that are produced incrementally and event streams (); and
• requirements and guidance for gateways that preserve HTTP semantics across a bundle network, chiefly caching ().

This document builds on existing specifications wherever it can. The following functions are outside its scope; most are already covered by existing HTTP, DNS, or DTN specifications, which apply to gateways unchanged.

Directing clients to a gateway:

Clients reach a client-side gateway by the usual means of reaching an HTTP intermediary: by configuring it as a proxy, so that requests carry absolute-form targets (); or through DNS, by resolving the names of origins to the addresses of the gateway, for example with split-horizon DNS ().

Selecting a responder:

The mapping from an authority to the EID of a responder can be configured, or obtained from a resolution service, for example one built on DNS Service Binding records . gives the requirements that any such mechanism has to meet.

A companion document is expected to specify an SVCB-based mechanism.

Admission and capacity policy:

Which requests a gateway admits, and how it rations the capacity of a bundle path, are matters for each deployment. Gateways convey their decisions with existing HTTP mechanisms: 413 (Content Too Large), and 503 (Service Unavailable) with Retry-After ; 429 (Too Many Requests) ; and Problem Details . Quota policies can be advertised with the RateLimit fields .

Asynchronous and repeatable requests:

Clients can ask for asynchronous processing with Prefer: respond-async , resubmit unsafe requests without repeating their effect using the Idempotency-Key field , and divide large uploads into independent steps with Resumable Uploads for HTTP . describes how these apply at a gateway.

End-to-end security:

TLS terminates at the gateways (). Mechanisms that protect HTTP messages, rather than connections, pass through gateways unchanged: HTTP Message Signatures authenticate messages, Encrypted Content-Encoding protects content, and Digest Fields protect its integrity.

Cache control for DTN gateways:

Origin servers control caching at gateways with ordinary Cache-Control directives . Targeted Cache-Control fields provide the means by which directives could be addressed to DTN gateways alone; defining such a field is left to a future document.

Streaming media:

Segmented media formats such as HTTP Live Streaming were designed to traverse HTTP caches, and cross a gateway pair without adaptation.

Other application protocols:

CoAP, which already runs over a message-oriented transport, is carried over BP by ; existing mappings between HTTP and CoAP apply between the two. Tunnelling (CONNECT), WebSocket, and other protocols that require an interactive end-to-end connection are not supported ().

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the terms "bundle", "application data unit (ADU)", "bundle protocol agent (BPA)", "endpoint ID (EID)", "lifetime", "creation timestamp", and "bundle age" from ; the terms "intermediary", "gateway", "origin server", "user agent", "target URI", "safe", and "idempotent" from ; and the terms "shared cache", "stored response", "fresh", and "stale" from . Data structures are described using the Concise Data Definition Language (CDDL) . In this document, the source EID of a bundle is the EID carried in the Source node ID field of its primary block, and its destination EID is the EID carried in its Destination EID field ().

Requester:

A BP node that sends HTTP requests over BP as specified in this document and receives the corresponding responses. A requester is either a client-side gateway or a BP-native HTTP client.

Responder:

A BP node that receives HTTP requests over BP as specified in this document and returns responses. A responder is either an origin-side gateway or a BP-native HTTP origin server.

Client-side gateway:

A requester that receives HTTP requests from clients over conventional HTTP connections and forwards them over BP.

Origin-side gateway:

A responder that forwards the HTTP requests it receives over BP to origin servers over conventional HTTP connections, and returns their responses over BP.

Request ADU:

An ADU, formatted as specified in , that carries an HTTP request.

Response ADU:

An ADU, formatted as specified in , that carries an HTTP response.

Exchange:

A request ADU together with the response ADU or ADUs that answer it, identified by a correlation identifier ().

Applicability HTTP over BP has two principal uses: HTTP application-layer gateways () and BP-native HTTP applications (). compares it with other ways of bringing HTTP to a bundle network.

HTTP Gateways A pair of HTTP application-layer gateways, one at each edge of a bundle network, lets unmodified HTTP clients and origin servers communicate across it. Each gateway terminates the HTTP connections on its own side, and the gateways exchange requests and responses with each other using HTTP over BP. HTTP runs end to end, between client and origin server, while the transport beneath it changes from hop to hop:

HTTP Gateways at the Edges of a Bundle Network | | | | | | | | +-------------+ +-------------+ | | | client |<---->| client-side |<---->| origin-side |<---->| origin | | | IP | gateway | BP | gateway | IP | server | +--------+ +-------------+ +-------------+ +--------+ ]]>

The DTN architecture anticipated gateways of this kind. One of its stated aims is "to provide a common method for interconnecting application layer gateways and proxies", so that existing Internet applications that can be made to tolerate delay can "operate unmodified over a DTN-based network" (). HTTP over BP is that common method for HTTP: the protocol beneath the web, most application programming interfaces, and most streaming media. With it, the large body of existing HTTP clients, servers, tools, and libraries can be used across bundle networks without being rewritten. A gateway does more than translate between transports. HTTP's own means of coping with an expensive path work at the application layer, where only an intermediary can apply them: a client-side gateway answers what it can from its cache, collapses identical requests into one, and revalidates stored responses with conditional requests that cost little when nothing has changed (). Content can also be placed on the near side of a bundle network in advance, so that only cache fill crosses it. describes such a device as an application layer performance enhancing proxy, with "the same functionality as the corresponding regular proxy for the same application (e.g., relay MTA or Web caching proxy) but extended with link-specific optimizations of the application protocol operation". The design assumes disruption, not necessarily delay. On a bundle path with low latency the mechanisms described here for tolerating delay never engage: responses arrive before any client notices, and a gateway pair behaves as an ordinary caching reverse proxy, with nothing configured differently.

BP-Native HTTP An application on a BP node, such as software on a spacecraft or a surface asset, can act as an HTTP client by sending requests over BP itself, with no IP stack and no client-side gateway. It can reach an origin server on the Internet through an origin-side gateway:

A BP-Native HTTP Client | | | | | | | | +-------------+ | | | BP-native client |<--------------->| origin-side |<---->| origin | | | BP | gateway | IP | server | +------------------+ +-------------+ +--------+ ]]>

An application can likewise act as an origin server directly over BP, publishing resources that clients on the Internet reach through a client-side gateway, and a BP-native client can reach a BP-native origin server with no gateway at all. Such applications use HTTP's methods, status codes, caching, and media types, and existing HTTP libraries for constructing and parsing messages, rather than defining an application protocol of their own. A node can choose for itself whether to reach a service over IP, through a gateway, or over BP directly, and the HTTP semantics are the same in each case.

Alternatives There are other ways to bring HTTP to a bundle network, and each has a cost.

Application-specific protocols:

Applications can be rewritten to use BP directly, with an application protocol of their own. This suits purpose-built applications, such as spacecraft operations, but cannot be asked of HTTP software in general.

End-to-end transport:

TCP/IP or QUIC can be run end to end, either directly across the path or by carrying IP packets in bundles. These transports assume a contemporaneous end-to-end path: they spend round trips establishing and securing a connection, retransmit on short timers, and treat a path that stays silent for long as failed.

HTTP connections in bundles:

The bytes of an HTTP connection can be carried in bundles . This avoids IP, but inherits the connection's need for reliable, in-order delivery, which BP does not provide.

Carrying HTTP's messages, rather than its connections, avoids all of these costs.

Architecture HTTP is well suited to being carried as individual messages. Its semantics are defined independently of the protocols that carry them, and have already been mapped onto more than one transport, most recently QUIC . Each request and each response is a self-contained message. HTTP already defines the role of intermediaries (), which fields are end to end and which belong to a single connection (), and how intermediaries cache . This document therefore needs to specify little beyond the bundle hop.

Roles The protocol in this document operates between a requester and a responder. A requester is either a client-side gateway or a BP-native client; a responder is either an origin-side gateway or a BP-native origin server. The protocol is the same whichever kind each is, so any requester can exchange requests and responses with any responder. shows a client-side gateway as the requester and an origin-side gateway as the responder; shows a BP-native client as the requester. A BP-native origin server answers requests for its own authorities directly:

A BP-Native HTTP Origin Server | | | | | | | | +-------------+ | | | client |<---->| client-side |<--------------->| BP-native origin | | | IP | gateway | BP | server | +--------+ +-------------+ +--------------------+ ]]>

Requirements in this document that apply to every requester or every responder are stated in those terms; requirements specific to gateways are stated in terms of client-side or origin-side gateways. A single node can act in both roles, for example as a relay between two bundle networks, or as a gateway that serves clients in each direction (). Gateways are HTTP intermediaries (), and all of the requirements that and place on intermediaries apply to them. A client-side gateway commonly acts as a reverse proxy for the authorities it serves; it might also be configured as a forward proxy for "http" targets. In either case it terminates the client's HTTP connection, and TLS where used, and an origin-side gateway opens its own connection to the origin server. The bundle hop between them is protected with BPSec ().

Principles The mapping rests on four principles.

One message per bundle:

Each ADU carries exactly one complete HTTP message. A receiver can interpret every ADU on its own, without reference to any other bundle.

Explicit correlation:

How a response is correlated with its request depends on the HTTP version; some versions rely on the ordering of messages on a connection, and others use an explicit identifier (). BP preserves no ordering, so this mapping uses an explicit correlation identifier carried in an envelope around the HTTP message ().

No sequencing:

No sequence numbers, acknowledgements, or retransmission state exist at this layer. Reordering is harmless because exchanges are matched by identifier, not by arrival order; a duplicate response is discarded because it matches no outstanding exchange, and a duplicate request is recognised by the same identifier (). Nor is ordering provided between distinct exchanges, just as HTTP provides none between requests sent on different connections.

Connections end at the edges:

HTTP connections, and the TLS sessions that protect them, exist only between clients and client-side gateways and between origin-side gateways and origin servers. HTTP semantics are end to end; HTTP connections are not.

Endpoints and Addressing

Responder Endpoint A responder receives request ADUs at an endpoint registered for this service. The well-known endpoint is ipn-scheme service number TBD1 () at the responder's node; for example, ipn:977000.100.TBD1 is the responder endpoint of node 100 under allocator 977000 . A responder SHOULD support the well-known endpoint, so that requesters can reach it without additional configuration. A responder MAY also receive requests at other endpoints, which requesters learn by other means. A requester MUST address each request bundle to a singleton endpoint, because it admits a response only from a bundle whose source EID is the EID to which it sent the request ().

Requester Endpoint A requester sends each request bundle from a singleton endpoint at which it is registered, and receives the responses at that endpoint. A requester MUST NOT send a request bundle whose source EID is the null endpoint ID (), since there would be no endpoint to which to return the response. The requester's endpoint need not be the well-known service endpoint. A node that acts as both requester and responder MAY use one endpoint for both roles: the direction of each ADU is given by the Binary HTTP framing indicator ().

Selecting a Responder To send a request, a requester maps the authority component of the target URI to the EID of a responder. The mapping can come from configuration, including a default responder for authorities with no specific entry, or from a resolution service, for example one built on DNS Service Binding records . Specifying such a service is outside the scope of this document; whatever the mechanism:

• A specific mapping for an authority MUST take precedence over a default.
• The integrity of the mapping MUST be protected, since an attacker who can alter it can direct requests, and the responses that populate a shared cache, to a responder of its choosing ().
• A name with local scope, such as a single-label name or one under a special-use domain, MUST NOT be resolved using global resolution services.

A requester that finds no responder for an authority MUST NOT send a request ADU. A client-side gateway in that situation SHOULD respond with 502 (Bad Gateway) and a Proxy-Status field with the error type "destination_not_found".

ADU Format

Structure Each ADU consists of exactly one CBOR data item: an array whose first element is a version number (). The rest of the array is defined by the version; this document defines version 1, an array of four elements.

ADU Structure true, ; incremental (requests) ? 2 => true, ; final-segment (responses) ? -1 => uint, ; segment (requests and responses) * int => any ; options defined by future specifications } ]]>

A sender MUST use definite-length encoding for every data item in the ADU and MUST NOT repeat a key within the options map; senders SHOULD use the core deterministic encoding of . The ADU MUST contain no data after the array. A receiver MUST discard, without responding, an ADU that is not well-formed CBOR, that does not match the http-over-bp-adu rule of , that contains a duplicate map key, or that has trailing data. It then checks the version (); a version 1 ADU that does not match the http-over-bp-adu-v1 rule MUST likewise be discarded without responding.

Version The version element identifies the format of the remainder of the ADU. A receiver MUST discard, without responding, an ADU with a version it does not support. The version sits outside the structure it versions, so that a future version can change any other element.

Correlation Identifier The correlation identifier associates a response with its request. The requester generates it; the responder treats it as opaque and copies it unchanged into each response ADU it sends for that request. A requester MUST NOT use a correlation identifier that is already in use for another outstanding exchange from the same requester endpoint, except when retrying a request (). Identifiers SHOULD be at least 16 bytes long and generated by a cryptographically secure random number generator, so that an attacker cannot predict them (). A requester MAY instead encode its own state in the identifier, for example an authenticated token that lets it process responses without retaining per-exchange state, provided the result is equally unpredictable.

Options The options element is a map of integer keys to values, carrying metadata about the exchange that is not part of the HTTP message. Keeping this metadata out of the HTTP header and trailer fields ensures that no client or origin server can inject it, and that it never leaks to them (). The sign of a key indicates whether the option is critical:

• An option with a non-negative key is elective. A receiver MUST ignore an elective option that it does not understand, or that is defined only for the other direction.
• An option with a negative key is critical. A responder that receives a request ADU containing a critical option that it does not understand MUST NOT process the request and SHOULD respond with 501 (Not Implemented) and a Proxy-Status field whose "details" parameter identifies the option. A requester that receives a response ADU containing a critical option that it does not understand MUST NOT process the response: if the ADU passes the admission check of , the requester fails the exchange (); otherwise it discards the ADU.

Key 0 is reserved. The options defined by this document are listed in ; further options are registered as described in . Options Defined by This Document

Key	Name	Used in	Value	Reference
1	incremental	Requests	true
2	final-segment	Responses	true
-1	segment	Requests, responses	uint

The timing of an exchange is not carried in options; it is taken from the bundles themselves ().

HTTP Message The message element contains one Binary HTTP message . A sender MUST use the known-length format: framing indicator 0 for a request and 1 for a response (). A receiver MAY treat a message in the indeterminate-length format as invalid; the entire message is present in the ADU, so that format offers no benefit here. The framing indicator determines the direction of the ADU: an ADU whose message is a request is a request ADU, and one whose message is a response is a response ADU. The request control data () carries the method and the scheme, authority, and path of the target URI. The authority MUST NOT be empty. A request MAY include a Host header field, in which case it MUST identify the same authority as the control data; a responder MUST treat a request in which they differ as malformed (compare ). A responder MUST use the authority in the control data, not the Host field, to identify the target. A response message carries exactly one final response. A responder SHOULD NOT include informational (1xx) responses (): they are hints about a connection that no longer exists by the time the response is delivered. A requester MUST ignore any that are present. Messages MAY carry trailer fields, and MAY be padded (). Padding obscures message length only when the ADU is also encrypted ().

Field Handling No HTTP connection spans the bundle hop, so fields that describe a connection have nothing to apply to. Before encoding a message, the sender MUST remove:

• the connection-specific fields listed in : Connection and every field it names, Proxy-Connection, Keep-Alive, TE, Transfer-Encoding, and Upgrade. recommends removing these; this document requires it;
• the proxy authentication fields of , which apply only to the hop on which they were received; and
• fields consumed by the gateway itself, such as Client-Cert and Client-Cert-Chain , which carry client credentials that are not to be forwarded beyond the gateway that verified them.

A client-side gateway has to receive the complete request content before it can encode the request, so it satisfies an Expect: 100-continue expectation itself, sending either 100 (Continue) or a final response as requires of a server, and removes the expectation from the request before encoding it. Each gateway MUST record itself in the Via header field as requires of an HTTP-to-HTTP gateway. A client-side gateway appends its entry to the request before encoding it; an origin-side gateway appends its entry before forwarding the request to the origin server. Each SHOULD likewise append its entry to the response. Gateways SHOULD use a pseudonym rather than a host name as the received-by value, as permits. The received-protocol that an origin-side gateway records for a request received over BP is an open issue (). An origin-side gateway with a clock that receives a response without a Date header field from the origin server MUST add one before encoding the response, as requires of any recipient that forwards such a response.

Exchange Procedures

Bundle Age and Expiry The procedures in this section use two properties of each bundle that the BPA delivers: its bundle age, the time that has elapsed since it was created, and its expiry, the time at which its age will exceed its lifetime. Under , bundle age is determined from the bundle's creation timestamp where that timestamp is not zero and the receiving node's clock is accurate, and otherwise from the Bundle Age block (), so both properties are available whether or not the nodes involved have accurate clocks. The timing of an exchange is carried by its bundles rather than in the ADU. The lifetime of the request bundle bounds the whole exchange (), the response bundle expires no later than the request bundle (), and the bundle age of a response measures the time it spent in transit (). does not specify the interface between a BPA and the application agent. A requester or responder relies on its BPA to report the bundle age and expiry of each bundle it delivers.

Sending a Request To send a request, a requester:

1. selects a responder for the target URI ();
2. constructs the request message as specified in and ;
3. generates a correlation identifier () and constructs the request ADU;
4. requests transmission of a bundle whose payload is the request ADU, whose destination EID identifies the responder endpoint, and whose source EID identifies the requester endpoint (); and
5. records the exchange: its correlation identifier, the responder endpoint to which it was sent, and its deadline ().

Each request ADU is sent in a bundle of its own. A requester MUST NOT place more than one ADU in a bundle. The BPA can fragment the bundle in transit (); the responder's BPA reassembles it before delivery. The lifetime of the request bundle bounds the whole exchange, since no response can be sent after the request bundle expires (). It SHOULD be long enough for the request to reach the responder and for the response to return, for example as estimated from a contact plan, and no longer than the period during which the requester will use a response. A requester MAY request bundle deletion status reports () so that it can detect failure early (); it SHOULD NOT request other status reports, except for diagnostics, because each report adds traffic to the bundle network. A requester MUST NOT automatically retry a request whose method is not idempotent (). It MAY retry a request whose method is safe or idempotent, for example after a deletion status report or once its deadline has passed. A retry SHOULD reuse the correlation identifier of the original request, so that a response to either attempt completes the exchange and a response to the other is discarded as a duplicate. The exchange's deadline then becomes the expiry of the retry's request bundle ().

Processing a Request When an ADU is delivered to a responder (), the responder MUST discard it, without responding, if:

• the ADU is not valid as specified in , or has an unsupported version ();
• its message is a response;
• the source EID of the bundle that carried it is the null endpoint ID; or
• the bundle's "ADU is an administrative record" flag is set.

If the message is not a valid Binary HTTP message () or is malformed as described in , the responder SHOULD respond with 400 (Bad Request). If the request contains a critical option the responder does not understand, it proceeds as specified in . Otherwise the responder handles the request. A BP-native origin server handles it as an origin server would. An origin-side gateway forwards it to the origin server as an HTTP gateway (): it identifies the origin from the target URI, establishes a connection, verifying the server's certificate for an "https" target as requires, applies the field handling of , and sends the request. A responder that has a cache MAY answer from a stored response under the rules of . An origin-side gateway SHOULD apply a policy that restricts the destinations it will contact (). A request bundle that expires before it is delivered is deleted by the BPA (), so a responder does not process a request after its requester has stopped waiting for the response. A responder MAY also discard, without processing, a request that it estimates cannot be answered before the request bundle expires, for example from a contact plan. A responder can receive the same request more than once. A requester can retry a request whose method is safe or idempotent (), and the responder can simply process it again, as in HTTP. A request whose method is not idempotent is never retried automatically, but BP can duplicate the bundle that carries it, and re-executing the request could repeat its effect. For such requests, a responder SHOULD recognise a duplicate by the source EID of the request bundle together with its correlation identifier and, rather than processing the request again, re-send the response it gave to the first copy, or send nothing if that response is not yet complete. A responder that does so SHOULD retain its record of each exchange at least until the request bundle expires (). A re-sent response is subject to the same lifetime bound and Age requirement as any other ().

Sending a Response To answer a request, the responder constructs a response ADU with:

• version 1;
• the correlation identifier copied, unchanged, from the request ADU;
• any options that apply; and
• the final response, encoded as specified in and .

It requests transmission of a bundle whose payload is the response ADU, whose destination EID is the source EID of the request bundle, and whose source EID is the destination EID of the request bundle. The responder MUST set the lifetime of the response bundle so that it expires no later than the request bundle (), and SHOULD NOT send a response ADU after the request bundle has expired. A responder sends one response ADU for each request it processes, except as specified in . A requester measures the transit of a response from the creation of the bundle that carries it (). A responder that sends a response some time after generating it, or after receiving it from the origin server, MUST therefore include an Age field that accounts for the delay. This is the case when it answers from a stored response, as already requires, and when it re-sends a response to a duplicate request (). When an origin-side gateway cannot complete the exchange with the origin server, it responds with an error response such as 502 (Bad Gateway) or 504 (Gateway Timeout), carrying a Proxy-Status field that identifies the gateway and the error type, for example "dns_error", "connection_refused", "connection_timeout", "tls_certificate_error", or "http_response_timeout". Clients can then distinguish a failure beyond the origin-side gateway from a failure in the bundle network ().

Receiving a Response When an ADU whose message is a response is delivered to a requester, the requester MUST discard it unless both:

• the requester has an outstanding exchange with the ADU's correlation identifier; and
• the source EID of the bundle that carried the ADU is the EID to which the request of that exchange was sent.

This check is the requester's defence against forged responses, which could otherwise poison a client-side gateway's shared cache for every client it serves; its strength depends on the authentication of the bundle's source (). A requester MUST discard a response ADU for an exchange that has already completed, except as specified in . Otherwise, the response completes the exchange. The requester processes the response as an HTTP intermediary or client would: a client-side gateway applies the field handling of , calculates the response's age (), stores it if permitted (), and forwards it to the client, or retains it for the client to collect ().

Deadlines and Failure A requester assigns each exchange a deadline, after which, if no response has been received, the exchange has failed. The deadline SHOULD be the expiry of the request bundle, or of the latest retry (): no response can arrive after it, since a response bundle expires no later than the request bundle (). When an exchange fails, a client-side gateway answers any client waiting for it with 504 (Gateway Timeout) and a Proxy-Status field with the error type "http_response_timeout". A requester that receives a bundle status report () asserting that the request bundle was deleted MAY fail the exchange immediately. A client-side gateway that does so SHOULD answer with 504 (Gateway Timeout) and a Proxy-Status field with the error type "bp_bundle_deleted" (), whose "bp-reason" parameter carries the reason code from the status report. As with any 504 response, the failure of an exchange does not show that the request was not processed: the response could have been lost or delayed after the responder acted on it. After a safe request fails, a client-side gateway SHOULD NOT send the same request again until a configured interval has passed, so that repeated client requests do not send a stream of bundles toward an unreachable responder.

Extended Exchanges

Incremental Responses Some responses are produced slowly: an origin server sends the header section promptly, then content over an extended period. No responder can send content that has not yet been produced, and holding the response until it is complete delays every byte of it. A requester that is able to assemble a response from parts indicates this by including the incremental option (key 1) in its request ADU. A responder that receives a request with the incremental option MAY return the response as a sequence of 206 (Partial Content) responses (), each in its own response ADU with the request's correlation identifier. Each of these responses:

• is complete and self-contained, with the full header section of the response and a single Content-Range header field () covering exactly the content it carries;
• carries the same strong validator () as every other response in the sequence; and
• carries the complete length of the representation in its Content-Range field if that length is known when it is sent, and "*" otherwise.

The responder chooses when to send each part. A response that is complete before the responder would send its first part is sent as a single ordinary response. The requester combines the parts as and allow a cache to combine partial content; their order of arrival is immaterial. The exchange remains open until the requester holds the complete representation or its deadline passes; a requester that asks for an incremental response sets the lifetime of the request bundle to cover the time the response will take to complete. Once the complete length is known, the requester can recover any missing range with an ordinary range request in a new exchange. A requester MUST NOT serve the combined representation as complete until it is complete; it MAY answer a client's range request from content already received (). A responder SHOULD bound the resources it spends on any one incremental response, such as bytes, parts, and elapsed time. A responder that abandons a response before it is complete SHOULD send a final response ADU containing a 502 (Bad Gateway) response with a Proxy-Status field (for example with the error type "http_response_body_size"). On receiving it, the requester fails the exchange and MUST NOT treat the content received so far as a complete representation. An origin-side gateway might need to supply a strong validator for a response that has none. Whether, and how, it should do so without creating a validator the origin server would not recognise is an open issue ().

Event Streams An event stream (the text/event-stream media type ) has no end, so it can be carried neither as a single response nor as a finite sequence of parts. Its contract is nevertheless tolerant of delay: events are delivered in order, in one direction, eventually, and a client can resume a stream from the identifier of the last event it received. This document carries an event stream as a sequence of finite segments. This section is less mature than the rest of the document, and could move to a companion document. To request segment K of an event stream, a requester sends a GET request for the stream's target URI with the segment option (key -1) set to K. The option is critical, so a responder that does not support segments refuses the request () instead of opening a response that never ends. An origin-side gateway that supports segments:

• maintains one subscription to the origin server's event stream for each target URI and credential scope, shared by every requester that requests segments of it;
• divides the events it receives into numbered segments at boundaries of its choosing, such as a count of events, a size, or an interval, and never splits an event across segments;
• answers a request for segment K, once that segment is closed, with a 200 (OK) response of type text/event-stream whose content is the complete events of the segment, in a response ADU carrying the segment option set to K;
• holds a request for a segment that is still open until the segment closes, and closes a segment early, even if it holds no events, so that its response can be delivered before the request bundle expires; and
• marks the last segment, when the origin server ends the stream, with the final-segment option (key 2).

A closed segment never changes, so a requester can store it and serve it to any number of local clients. A client-side gateway serves each client a genuine text/event-stream response on a connection that it holds open, releasing events strictly in order; a missing segment holds back later ones until it is recovered. The gateway requests further segments while it has clients for the stream, and MAY request segment K+1 before segment K arrives, to hide the latency of the path. It maps a client's Last-Event-ID to a position within the segments it holds. Other unbounded response types, such as newline-delimited records, could be segmented in the same way, given a rule for event boundaries; such types do not identify themselves, so a gateway would need configuration to recognise them.

Unsupported HTTP Features The CONNECT method () establishes a tunnel whose contents are interactive and opaque to HTTP. A requester MUST NOT send a CONNECT request in a request ADU. A client-side gateway that receives a CONNECT request asking it to establish a tunnel across the bundle network SHOULD respond with 501 (Not Implemented). Protocol upgrade () replaces HTTP on a connection, and no connection spans the bundle hop. A client-side gateway that receives a request to upgrade to WebSocket , whether through the Upgrade field or through extended CONNECT , SHOULD respond with 501 (Not Implemented) rather than forward it with the Upgrade field removed, which would return a response that the client did not ask for. Applications that need messages in both directions can use an event stream for one direction () and individual requests for the other.

Gateway Considerations This section gives requirements and guidance for gateways. None of it affects the format of ADUs or the exchange procedures, and gateways that make different choices interoperate.

Caching Much of the value of a client-side gateway lies in its cache: every request it answers locally is one that does not cross the bundle network. A client-side gateway SHOULD act as a shared cache . A BP-native client benefits from a private cache in the same way, and the guidance in this section applies to it as well, except where it concerns shared caches or requests from multiple clients.

Collapsing requests:

A client-side gateway SHOULD collapse requests (): when a request could be satisfied by the response to a safe request for which an exchange is already outstanding, the gateway awaits that response instead of starting another exchange. The key on which requests are collapsed MUST distinguish requests made with different credentials, whether carried in Authorization or Cookie fields or otherwise, and SHOULD include the request fields to which the response is expected to vary. A gateway MUST NOT collapse unsafe requests.

Validation:

When it revalidates a stored response, a gateway SHOULD send a conditional request carrying the stored validators, so that an unchanged resource costs only a small 304 (Not Modified) response ADU. A gateway SHOULD answer a client's conditional request from a stored response wherever allows, without starting an exchange.

Serving stale responses:

permits a cache to serve a stale response where it is explicitly permitted "by configuration in accordance with an out-of-band contract". A gateway deployed in front of a constrained or intermittent path is such a configuration, and MAY serve stale responses within configured limits, for example while revalidating in the background or after an exchange has failed (compare ). Nothing in this document relaxes the response directives of : a gateway MUST NOT serve a stale response that a directive such as no-cache, must-revalidate, proxy-revalidate, or s-maxage prohibits, and MUST generate an accurate Age header field whenever it serves a stored response without validation.

Request directives:

Cache request directives are advisory (). A gateway MAY decline to honour directives, such as max-age, min-fresh, and no-cache, that would oblige it to start an exchange across the bundle network. It SHOULD honour only-if-cached, max-stale, and no-store, which cost nothing on the path.

Invalidation:

On receiving a non-error response to an unsafe request, a gateway invalidates stored responses as requires.

Pacing:

A gateway MAY enforce a minimum interval between exchanges for the same resource. When it does so, and no stored response can be served, it responds with 504 (Gateway Timeout), which it MAY accompany with a Retry-After field () giving the time at which a new exchange will be allowed. Pacing never extends the circumstances in which a stored response may be served.

Calculating Age A requester that stores or forwards a response calculates its age as specifies. That calculation's corrected_age_value adds to the received Age value the response_delay: the time between sending the request and receiving the response, the full round trip. Over a bundle path that round trip can be long, and much of it elapses before the response exists: the request's transit, and any time it waited for a contact. Charging all of it against the response's freshness lifetime roughly halves the usable lifetime on a symmetric path, and on a long-delay path can make every response stale on arrival. The bundle age of the response bundle (), as reported by the requester's BPA when the response is delivered, is the time that has elapsed since the responder requested its transmission: the time the response spent in transit. The requester MAY use it as transit_delay in place of response_delay: The result is the response's age when the responder sent it, plus the time it has since spent in transit. Any delay at the responder before it sent the response is carried in the Age field (). The apparent_age calculation of would also exclude the request's transit, but relies on the origin server's clock, in the Date field, being synchronised with the requester's. A gateway cannot know whether an origin server's clock is synchronised. Bundle age is instead determined by the BPAs on the path, from the creation timestamp where the clocks of the responder's and requester's nodes are accurate, or from the Bundle Age block, which needs no synchronised clocks (). A requester whose BPA does not report the bundle age of a response uses response_delay as specifies. A requester MUST NOT treat a response as having an age of zero when it arrives; that would conceal the transit delay that the Age field exists to disclose.

Responding to Clients During an Exchange A client expects a timely response, but over a long-delay path an exchange can outlast the client's patience. How a client-side gateway answers a client while an exchange is outstanding is local to the gateway. The following strategies are available, and gateways can combine them.

Holding:

The gateway holds the client's connection open until the response arrives, or the exchange fails, and then responds normally. Holding is transparent whenever the round trip is shorter than the client's timeout, and is the only safe choice for programmatic clients, which would misinterpret anything else.

Polling in place:

For a top-level navigation by a browser, the gateway can respond with 202 (Accepted), a Retry-After field, and a document that refreshes itself, so that the browser requests the same URI again later and receives the stored response once it has arrived. Because a programmatic client treats any 2xx response as success, and would consume the 202 response body as though it were the resource, a gateway SHOULD respond with 202 only when the request is known to be a navigation, for example from the Sec-Fetch-Dest request field , and not on the strength of the Accept field.

Status resources:

For an unsafe request, the gateway can respond with 303 (See Other) referring to a status resource, under an unguessable URI, from which the client retrieves the eventual response. A client can ask for this behaviour with Prefer: respond-async , a preference that a proxy may honour on its own (). The Idempotency-Key field lets a client resubmit an unsafe request without repeating its effect.

Retry intervals:

Where a gateway can estimate when a response will arrive, for example from a contact plan, it SHOULD derive the intervals it gives clients in Retry-After fields from that estimate, rather than from a fixed value.

Clients that send large or open-ended request content can divide it into finite steps with Resumable Uploads for HTTP , each step being an ordinary exchange.

Ordering No ordering is provided between exchanges (). Two unsafe requests sent in succession can reach the origin server in either order. A client that needs one request to be processed after another has to wait for the response to the first before sending the second.

Chained Gateways A node can act as both responder and requester, receiving requests over one bundle network and forwarding them over another. Each such node is an intermediary in its own right, and records itself in the Via field (). A misconfigured chain can form a loop; a gateway SHOULD detect loops, using its Via entries or the CDN-Loop field , and respond with 502 (Bad Gateway) and a Proxy-Status field with the error type "proxy_loop_detected".

Operational Considerations

Lifetimes and deadlines:

Bundle lifetimes, and so exchange deadlines, need to match the latency of the path; contact plans, where available, give the best estimates. Because a response bundle expires no later than the request bundle it answers, a request that is delivered late in its lifetime leaves little time for the response to return, so the lifetime of the request bundle needs to cover both directions. Values that are too short fail exchanges that would have completed; values that are too long hold resources for responses that will never be used.

Clocks:

Exchange deadlines and age calculation () depend on the BPAs' determination of bundle age. BP nodes generally keep accurate time; a deployment with clockless nodes relies on the Bundle Age block, which every node on the path then needs to maintain.

Message size:

Each HTTP message is a single ADU, carried, and if necessary fragmented, by the BP layer. Deployments typically limit message sizes. A client-side gateway that refuses request content as too large responds with 413 (Content Too Large); a responder that refuses a response as too large responds with 502 (Bad Gateway) and a Proxy-Status field with the error type "http_response_body_size".

Round trips:

Some HTTP patterns cost a round trip each: redirects, authentication challenges, and preflight requests. Over a long-delay path each of these can cost hours. Origins that expect to be reached across a bundle network can be designed to avoid them, for example by accepting credentials sent preemptively rather than challenging for them.

Time-limited authorisations:

Signed URIs, tokens, and licence exchanges that expire within less than the latency of the path expire in transit. This is a property of the origin's security design, which no gateway can work around.

Security Considerations

Trust Model TLS terminates at the gateways, so there is no end-to-end TLS between client and origin server. A client entrusts the client-side gateway with the content of its requests and responses, as it would any reverse proxy that terminates TLS, and a gateway presents certificates only for names it is authorised to serve. The origin-side gateway authenticates the origin server (). Intercepting TLS connections to arbitrary origins by means of a locally installed certification authority is outside the scope of this document; it exposes all traffic to the gateway, defeats certificate pinning, and is appropriate only where the operator controls the clients. Between BP-native endpoints, and between a BP-native endpoint and a gateway, there is no TLS at all: BPSec is the only protection on the bundle hop (), and the authenticated source of a bundle takes the place of the TLS server identity. A BP-native client trusts the responder it has selected for an authority () as it would trust an origin server whose certificate it had verified, and needs that selection to be equally well protected.

Protecting the Bundle Hop Requesters and responders MUST support BPSec . This document does not mandate a particular security context; the choice is left to the deployment, for example the COSE context . Whatever the context, the protection of each ADU needs to provide three things:

Confidentiality and integrity of the ADU:

Every ADU SHOULD be protected by a Block Confidentiality Block (BCB) that targets the payload block. Every BCB security context provides authenticated encryption (), so the BCB both conceals the ADU and protects its integrity.

Integrity of the primary block:

The BCB's security context SHOULD include the primary block in its additional authenticated data, so that the primary block, which a BCB cannot conceal, is bound to the ADU. The primary block carries the source EID of the bundle, on which response admission depends, and its creation timestamp and lifetime, which bound the exchange.

Authentication of the source:

Integrity alone does not show who produced the bundle. Where a BCB is keyed so that only the two peers could have produced it, for example with a key shared between them or with key agreement between their static keys, the BCB also authenticates the source of the bundle. Where it is not, for example when the key is agreed using an ephemeral key of the sender's and the recipient's public key alone, anyone who knows the recipient's public key can produce a valid BCB, with any source EID in its primary block. A sender SHOULD then also protect the payload with a Block Integrity Block (BIB) that is signed with a key bound to the bundle's source EID, and that the BCB also encrypts (). A recipient MUST NOT treat the source of a bundle as authenticated unless one of these conditions holds.

Without BPSec, an attacker on the path can read requests and responses, including credentials, and can forge responses. A deployment that relies on protection at another layer needs to document that dependency.

Response Admission and Cache Poisoning A requester accepts a response only for an outstanding exchange, and only from the endpoint to which it sent the request (). Where the source of the bundle is authenticated, no third party can inject a response. A forged response accepted by a client-side gateway could otherwise be stored in its shared cache and served to every client. For the same reason, the parts of an incremental response are required to share a strong validator ().

Resolution Integrity Response admission is only as strong as the mapping from authority to responder (). An attacker that can alter the mapping can direct requests, and the responses that populate a shared cache, to a responder of its choosing. Mappings obtained from DNS need to be validated with DNSSEC; where that is not possible, mappings need to be configured or pinned.

Correlation Identifiers Unpredictable correlation identifiers () make blind injection of responses harder where the bundle hop is not protected. They are not a substitute for BPSec.

Server-Side Request Forgery An origin-side gateway fetches whatever a request names, which makes it a means of reaching hosts on its own network. An origin-side gateway SHOULD refuse, unless configured otherwise, to contact private, loopback, and link-local addresses, including cloud metadata services, and SHOULD support restricting the origins it will contact to a configured set. It needs to apply these checks to the addresses that names resolve to, not only to literal addresses in the target URI. A gateway that refuses a request because of the address it would contact responds with 502 (Bad Gateway) and a Proxy-Status field with the error type "destination_ip_prohibited"; one that refuses it because the origin is not in its configured set responds with 403 (Forbidden) and the error type "http_request_denied".

Replay BPSec does not itself prevent replay (). A replayed request bundle carrying a request whose method is not idempotent could cause the request to be acted on again. The responder's detection of duplicate requests () suppresses replays while its records are retained, and a replayed bundle expires when the original does, since its creation timestamp and lifetime are in the primary block, which the BCB authenticates. Together, these bound the window in which a replay can have any effect. The bound does not hold for a bundle whose creation time is zero: its age is carried in the Bundle Age block, which each forwarding node updates and so cannot be protected end to end, and a replaying node can reset it. A requester SHOULD send each request whose method is not idempotent in a bundle with a non-zero creation timestamp, and with a lifetime no longer than the exchange needs.

Forged Status Reports A bundle status report is generated by whichever node deleted the bundle, not by the responder, so a requester cannot check its source against the exchange. A requester that fails an exchange on receiving a deletion status report () can be made to fail it early by a forged report. Since the request can still be delivered and acted on, this denies the client its response rather than preventing the request. A requester SHOULD act on a deletion status report only if it is protected by BPSec, for example by a BIB whose source the requester trusts, or else treat it as a hint and wait for the exchange's deadline.

Timing Integrity The bundle age of a response determines the age that a requester computes for it (), and so how long the response is served. An attacker that could alter it could make a response appear fresher, or more stale, than it is. Where the response bundle has a non-zero creation timestamp, that timestamp is in the primary block, which the BCB authenticates. Where its creation time is zero, the age is taken from the Bundle Age block, which each forwarding node updates and so cannot be protected end to end; a deployment that relies on clockless nodes trusts the nodes on the path to maintain it honestly.

Resource Exhaustion A small request can elicit a large response, and an incremental response or an event stream can elicit a long sequence of them. Responders need to bound the resources any one request can consume, and both roles need to bound the number of outstanding exchanges, held client connections, and event-stream subscriptions. Requests for bundle status reports add traffic to the bundle network and should be limited accordingly.

Credentials and Privacy Authorization and Cookie fields cross the bundle network inside ADUs and need the confidentiality that a BCB provides. Client certificates are verified at the client-side gateway and never forwarded (). A shared cache does not store responses to requests with Authorization fields unless the origin server permits it (), and gateways do not collapse requests made with different credentials (). Via pseudonyms () avoid disclosing the topology of gateway deployments. Padding Binary HTTP messages () can obscure their lengths from an observer when the ADU is encrypted.

IANA Considerations

Well-Known Service Number This document requests that IANA register the following entry in the "'ipn' Scheme URI Well-Known Service Numbers for BPv7" registry established by , assigning a value from the Standards Action range (128-255): Service Number Registration

Value	Description	Reference
TBD1	HTTP over BP	(this document)

HTTP over BP Options Registry This document requests that IANA create a new registry titled "HTTP over BP Options". Each entry records:

Key:

An integer. Negative keys denote critical options and non-negative keys elective options ().

Name:

A short descriptive name.

Used in:

Requests, responses, or both.

Value:

The type of the value, in CDDL.

Reference:

The specification that defines the option.

The registration procedures () are: HTTP over BP Options Registration Procedures

Range	Registration Procedure
-24 to 23	Standards Action
-65536 to -25, and 24 to 65535	Specification Required
Less than -65536, and greater than 65535	Private Use

The initial contents of the registry are the options in , each with this document as the reference, together with key 0, marked "Reserved".

HTTP Proxy Error Type This document requests that IANA register the following entry in the "HTTP Proxy Error Types" registry established by :

Name:

bp_bundle_deleted

Description:

The intermediary was notified by the Bundle Protocol that a bundle carrying the request was deleted before it was delivered, for example because its lifetime expired or no route to its destination was available.

Extra Parameters:

bp-reason: an Integer containing the reason code from the bundle status report ().

Recommended HTTP Status Code:

504

Response Only Generated by Intermediaries:

true

Reference:

(this document)

References Normative References This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors. This document defines a binary format for representing HTTP messages. This document updates the specification of the 'ipn' URI scheme previously defined in RFC 6260 and the IANA registries established in RFC 7116. It also updates the rules for the encoding and decoding of these URIs when used as an Endpoint Identifier (EID) in the Bundle Protocol version 7 (BPv7) as defined in RFC 9171. These updates clarify the structure and behavior of the 'ipn' URI scheme, define new encodings of 'ipn' scheme URIs, and establish the registries necessary to manage this scheme. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. This memo provides information for the Internet community. This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community. This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes. The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or s and long polling). [STANDARDS-TRACK] This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request. This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This memo introduces a content coding for HTTP that allows message payloads to be encrypted. This document describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 7 of this protocol. This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. This document defines the CDN-Loop request header field for HTTP. CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop. The new header field can be used to identify the error and terminate the loop. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches. It also defines one such header field, the CDN-Cache-Control response header field, which is targeted at content delivery network (CDN) caches. The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This document describes HTTP extension header fields that allow a TLS terminating reverse proxy (TTRP) to convey the client certificate information of a mutually authenticated TLS connection to the origin server in a common and predictable manner. This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. This document describes the encapsulation of HTTP requests and responses in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. The Johns Hopkins University Applied Physics Laboratory This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, organized by algorithm families, and for public key certificates are included for BPSec interoperation. This document updates BPSec RFC 9172 by providing Concise Data Definition Language (CDDL) rules for extensible security block content. UPC UPC The Bundle Protocol (BP) was designed to enable end-to-end communication in challenged networks. The Constrained Application Protocol (CoAP), which was designed for constrained-node networks, may be a suitable application-layer protocol for the scenarios where BP is used. This document specifies how CoAP is carried over BP. The HTTP Idempotency-Key request header field can be used to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant. Team Digitale, Italian Government Red Hat Microsoft This document defines the RateLimit-Policy and RateLimit HTTP header fields for servers to advertise their quota policies and the current service limits, thereby allowing clients to avoid being throttled. Transloadit Apple Inc. Apple HTTP data transfers can encounter interruption due to reasons such as canceled requests or dropped connections. If the intended recipient can indicate how much of the data was processed prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. WHATWG W3C This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security (BPSec) implementations. These security contexts are intended to be used both for testing the interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined or otherwise required for a network.

Examples This appendix shows one exchange in full. A client-side gateway, with Via pseudonym "gw-a" and endpoint ipn:977000.1.4096, forwards a client's request for https://example.com/status.json to an origin-side gateway, with pseudonym "gw-b" and endpoint ipn:977000.2.TBD1. The path takes 20 minutes in each direction.

Request The client-side gateway sends the request at 11:40:00 UTC on 23 October 2026. It will wait for the response until 12:40:00, so it gives the request bundle a lifetime of 60 minutes. The request message is: The request ADU, in CBOR extended diagnostic notation (), is: The 98 bytes of the encoded ADU are:

Response The request is delivered at 12:00:00. The origin-side gateway appends its own Via entry, forwards the request to the origin server, and receives the response at 12:00:00.250. It appends its Via entry to the response, and sends it at once, in a bundle whose lifetime of 2399.75 seconds makes it expire with the request bundle at 12:40:00. The response message is: The response ADU is: The 160 bytes of the encoded ADU are:

Age The response is delivered to the client-side gateway at 12:20:00.250. The response carries no Age field, so age_value is 0. The client-side gateway's BPA reports the response bundle's age as 1200 seconds. Using it as transit_delay (), the response's age on arrival is 1200 seconds and it remains fresh for a further 2400 seconds. Using the response_delay of , which here is the full round trip of about 2400 seconds, the response's age on arrival would be 2400 seconds, and it would remain fresh for only 1200 seconds. The difference is the 20 minutes the request spent in transit, before the response existed.

Design Rationale

Why Binary HTTP:

Binary HTTP represents a complete HTTP message independently of any HTTP version or connection, which is exactly what one message per bundle requires. It is compact, already deployed, and designed to be encapsulated.

Why an envelope rather than header fields:

The correlation identifier and options could have been carried as HTTP fields inside the Binary HTTP message. They are kept in a separate envelope so that no client or origin server can set them, and so that gateways need not strip them before forwarding messages. The envelope can also carry a version outside the structure it versions.

Why no timing options:

The lifetime of the request bundle bounds the exchange, and the bundle age of the response measures its transit (). Both are carried by the bundle, determined by the BPA whether or not the nodes have accurate clocks, and, where they come from the primary block, protected with it (). Repeating them in the ADU would add fields that need clocks and that could disagree with the bundle's own.

Why not Oblivious HTTP:

Oblivious HTTP also encapsulates Binary HTTP, but adds encryption under a separate key infrastructure. BPSec already protects the bundle hop, using the keys the bundle network provisions.

Why no sequence numbers:

Every ADU is self-contained, exchanges are matched by identifier, and parts of incremental responses are placed by their Content-Range. Nothing depends on the order of arrival, so there is nothing for sequence numbers to repair.

Why gateways rather than tunnels:

A gateway can answer requests from its cache, collapse requests, and revalidate cheaply, which are the means by which HTTP copes with an expensive path. A tunnel can do none of these things, and needs the interactive end-to-end connection that a bundle network cannot provide.

Open Issues

• Via received-protocol: which received-protocol an origin-side gateway should record for a request received over BP. Candidates include the client's HTTP version, which is not currently conveyed, or a new protocol name.
• dtn-scheme endpoints: whether to define a well-known dtn-scheme demux for this service, alongside the ipn service number.
• Validators for incremental responses: whether an origin-side gateway may supply a strong validator for a response that has none, or whether parts should instead be tied together by an envelope option.
• Event streams: how a requester joins a stream that is already in progress; how it learns that a responder's subscription has restarted and its segment numbering with it; how long responders retain closed segments, and how they answer requests for discarded ones; how streams answering unsafe requests are segmented; and whether this belongs in a companion document.
• Unknown critical options in requests: whether 501 (Not Implemented) is the right response.
• BPSec: whether its use should be required rather than recommended, and whether this document should name a security context that every implementation supports, given that the default security contexts are expected to be superseded.
• Age calculation: substituting transit_delay for response_delay () relaxes a requirement of , which says a cache "MUST interpret this value relative to the time the request was initiated". Whether this document needs to update RFC 9111, or can justify the calculation in some other way, needs review by HTTP caching experts.
• BPA interface: this document relies on the BPA reporting the bundle age and expiry of each delivered bundle (), which does not require of it.
• Media type: whether ADUs need a media type for storage or for transport outside BP.
• Naming: the name "HTTP over BP" was used by , which specified a different approach.

Acknowledgments TODO acknowledge.