HTTP Adaptation with Open Pluggable Edge Services (OPES)
Extracted elements (27)
Requiring an error when an OCP agent receives an unlisted application message part is intended to reduce subtle interoperability problems where an agent believes its sent parts are understood by the other side when they are actually being ignored or skipped.
Skipping 'control' HTTP messages (e.g., 100 Continue, CONNECT) by default is prohibited because sensitive information might be relayed via crafted 100 Continue responses, or malicious CONNECT requests may evade callout services intended to handle them. The OPES processor cannot unilaterally decide a message is not worth adapting.
OPES agents SHOULD use a single OPES-Via header-field rather than multiple equally-named fields to record a long trace. Using multiple equally-named extension header-fields is illegal from HTTP's point of view and may not work with OPES-unaware HTTP proxies.
An OCP agent MUST NOT send (i.e., must skip) absent application message parts. An OCP agent MUST send present non-auxiliary parts and MUST send those present auxiliary parts that were negotiated via the Aux-Parts parameter.
An OCP agent MUST send application message parts in the order implied by the profile parts lists. An OCP agent receiving an out-of-order part MAY terminate the transaction with an error.
An OPES processor MUST NOT send parts not listed as 'original' in the negotiated profile, and a callout server MUST NOT send parts not listed as 'adapted'. An OCP agent receiving an unlisted part MUST terminate the transaction with an error.
An OPES processor removing transfer encodings MUST remove the Transfer-Encoding header before sending the header part to the callout service, and MUST send a correct Transfer-Encoding header to the next HTTP recipient regardless of what the callout server returned.
An un-authoritative OPES processor MUST remove the Content-MD5 header unless it detects the HTTP message was not modified, in which case it MAY leave the header. HTTP intermediaries must not generate Content-MD5 headers per RFC 2616 section 14.15.
In the absence of explicit transfer-encoding negotiations, an OCP agent MUST NOT send transfer-encoded application message bodies. An agent MUST terminate the OCP transaction if it cannot remove all transfer encodings before sending a message body.
In the request profile, the callout server MUST send either adapted request parts or adapted response parts, not both. An OPES processor receiving adapted flow with parts from both lists MUST terminate the OCP transaction with an error.
OPES entities MUST NOT place required tracing entries in a message trailer. Optional entries MAY be placed in a trailer provided trailer presence does not violate HTTP protocol.
Unless explicitly configured to do otherwise, an OPES processor MUST offer all non-auxiliary original parts in Negotiation Offer (NO) messages. This prevents security flaws from selectively adapting only certain message types.
Unless specifically configured otherwise, an OPES processor MUST forward all HTTP messages for adaptation, including 1xx responses, POST/CONNECT/OPTIONS requests, and extension methods. Only OPES bypass instructions, configured rules, or OCP negotiation are acceptable exceptions.
When communicating with HTTP applications, OPES processors MUST ensure correctness of all computable HTTP headers (e.g., Content-Length, Content-MD5) in specifications they claim compliance with. By default, processors must validate and recalculate, add, or remove such headers.
Six HTTP application message part (am-part) atoms are defined: request-header, request-body, request-trailer, response-header, response-body, and response-trailer. Each corresponds to a well-defined portion of an HTTP message as specified in RFC 2616.
The Aux-Parts parameter allows negotiation of auxiliary application message parts in the HTTP response profile. An OPES processor MAY advertise available auxiliary parts; the callout server responds with a subset it requires.
The Content-Encodings parameter allows a callout server to indicate preferred content encodings (e.g., gzip). The OPES processor MUST NOT bypass a service just because the actual content encoding does not match the service's preferences.
The OPES-Bypass HTTP extension header is defined to request OPES system bypass. Its value is either '*' (bypass all OPES agents) or a list of bypass-entry values identifying specific OPES agents by absoluteURI.
The Pause-At-Body parameter allows a callout server to request a pause in original application message body transmission before dataflow starts. Its value is an offset into the non-auxiliary message body, equivalent to receiving a Want Data Paused (DWP) message.
The Preservation-Interest-Body parameter specifies a fixed-size prefix of the original message body for which Data Preservation Interest (DPI) would apply. An OPES processor MUST behave as if it received a DPI message with org-offset zero and org-size equal to the parameter value.
The Stop-Receiving-Body parameter implies a Want Stop Receiving Data (DWSR) message behavior before original dataflow starts. An OPES processor MUST behave as if it received a DWSR message with the corresponding offset.
Two HTTP extension headers carry OPES trace entries: OPES-System (required, identifies the OPES system) and OPES-Via (optional, identifies individual OPES agents). An OPES System MUST add its trace entry to OPES-System; other OPES agents MUST use OPES-Via.
Two OCP HTTP profiles are defined: the request profile (URI: http://www.iana.org/assignments/opes/ocp/http/request) and the response profile (URI: http://www.iana.org/assignments/opes/ocp/http/response). The response profile includes auxiliary original parts (request-header, request-body, request-trailer) that carry the original HTTP request as metadata for response adaptation.
IANA registers two HTTP OCP profile feature URIs using the registration procedure from OCP Core (RFC 4037): http://www.iana.org/assignments/opes/ocp/http/request and http://www.iana.org/assignments/opes/ocp/http/response.
Specific HTTP adaptation threats include rewriting the Request-URI of an HTTP CONNECT request or removing hop-by-hop Upgrade headers before an HTTP proxy can act on them. OPES agents MUST NOT perform such actions without HTTP client or server consent.
The AM-EL named parameter for Application Message Start (AMS) messages carries the entity length (size) of the request-body (request profile) or response-body (response profile) before transfer codings are applied. An OCP agent SHOULD announce this when known; MUST NOT send it when unknown.
The AM-Part named parameter for Data Use Mine (DUM) messages carries a single am-part token identifying which HTTP message part the DUM contains. An OCP agent MUST send AM-Part with every DUM message in an OCP transaction using an HTTP profile.