• Abstract and Figures
• Public Full-text

A Typed Model for Encoding-Based Protocol Interoperability ¤ Adam D. Bradley, Azer Bestavros, and Assaf J. Kfoury Boston University Department of Computer Science artdodge,best,[email protected] Abstract formalism which can be precisely and unambiguously related to the syntax of the protocol. The purpose of Documentation of the HTTP protocol includes precise this paper is to formally define and describe the con- descriptions of the syntax of the protocol, but lacks sim- tent model of the HTTP protocol, and to use this model ilarly precise specification of the semantics of messages to establish syntax-directed semantics for HTTP mes- and message bodies. Semantics are stated in English sages. The increased precision simplifies the assess- prose; while this makes the document more intuitively ment of the protocol's correctness and the interoperabil- accessible, it makes any sort of formal claims of cor- ity between multiple revisions and extensions. rectness or interoperability difficult to derive from the This paper is organized as follows: Section 2 specification itself. We propose “layered types”, a for- presents an overview of the HTTP protocol with partic- mal description of the interpretive semantics of HTTP ular emphasis upon the definition of its data model. Sec- message bodies based upon the stacked type syntax. tion 3 presents layered types, an unambiguous formal- This model allows us to formally declare semantics for ism representing the HTTP data model; layered types content-related HTTP headers and offers a precise way are employed in Section 4 as the basis for specifying of characterizing interoperability between current and syntax-directed semantics for HTTP messages under future protocol revisions and extensions. several versions of the HTTP protocol, and techniques for assessing correctness and interoperability of HTTP revisions and extensions are then discussed. 1. Introduction 2. An Overview of HTTP The fundamental premise of the web architecture is quite straightforward: the web provides a syntactically HTTP is a stateless client-server request-response consistent and semantically predictable interface to ar- protocol which roughly adheres to the REST (Repre- bitrary network-connected resources via the exchange sentational State Transfer) architectural style [8], mean- of representations (documents which represent the state ing (intuitively) that clients interact with servers by ex- of their creators) [8]. changing documents which represent the state of the While this core is fairly straightforward, the HTTP applications employing the protocol. These representa- protocol itself [7] has integrated a variety of (largely tions may have arbitrary underlying media types (text, performance-oriented) features [10] which have been audio, video, etc.) and may be encoded or transformed integrated with the protocol's syntax and specification in a variety of ways to support performance optimiza- in a largely ad hoc manner. The result is a specification tions and other features [10]. with uneven precision, making it difficult to directly A resource is any object which has a name (a URI) reason about its correctness [3, 4]. and can be accessed through an HTTP server. The One area of imprecision in the specification is with HTTP protocol is built around the exchange or request respect to the content model, i.e., the semantics of rep- and response messages. A message consists of a sin- resentations (message payloads) in their raw and de- gle control line which specifies the basic action or re- coded forms and the relationship between these seman- sult represented by the message, zero or more headers tics and the protocol's syntax. While Mogul has offered which modify or refine the meaning of the message, and an excellent intuitive content model [14] incorporated an optional message body carrying a (possibly encoded into a standards-track RFC [15], it is not presented as a or transformed) representation of the state of some re- source. A message may be either a request (a message ¤ This research was supported in part by grants from the National asking that some action be performed upon a particular Science Foundation (NSF), numbers ANI-9986397, ANI-0095988, resource) or a response (a message reflecting the result CCR-9988529, ITR-0113193, ANI-0205294, and EIA-0202067. of a request); clients are agents which transmit requests 1 and receive responses, while servers process requests Also note that a variant can always be coerced to be- by performing the requested action upon a resource and come an instance, but not vice versa. sending responses reflecting the results. A proxy is both a server and a client, forwarding requests and responses Entities An entity is an instance with zero or more from its own clients to upstream servers and back. A instance-manipulations applied to it. An instance- cache is a store of responses to past requests, usually manipulation is an operation which does not necessar- connected to a proxy or a client to reduce the number ily preserve the semantic integrity or “wholeness” of its of interactions with servers and thereby improve per- operand. For example: formance. ² Range selection (Content-Range header, multipart/byteranges Content-Type) 2.1. Data Model ² Delta coding [11, 15] An HTTP message body is a transformed and en- ² Cyclone coding [16]2 coded media object. The particular sequence of en- 3 codings and transformation applied to that object make ² Compression up what is called the message's data model or (equiv- ² Wrapping content in a cryptographic envelope alently) content model; the set of all such encod- ² Integrity checks (Content-MD5 header) ing/transform sequences supported by the protocol is the protocol's data model or (equivalently) content While an instance represents a whole thing (a rep- model. resentation which is of itself expressive of the state of In addition to structuring the order of encodings and the resource which produced it), an entity is not nec- transforms, the data model attaches a structured set essarily useful of itself, but rather may provide an ap- of semantics to various points within the encoding se- plication with enough information to be able to con- quence. Specifically, we say that there are four phases struct a complete instance from other information it also to the HTTP data model: variant, instance, entity, and possesses (e.g., by providing a delta against a previous 1 message; each corresponds with a distinct set of se- instance or filling a gap in a previous aborted down- mantics for agents which wish to interpret and use the load). More formally, content-codings will always be content of a message body, as described below. “lossless” with respect to the essential information of Variants A variant is a primitive value produced by a representation, while instance-manipulations may be a resource intended for direct presentation to a user, a “lossy” transforms (such that the lost information must non-HTTP-specific software component, or a resource. be acquired via a separate request or other out-of-band Variants usually take the form of individual documents, means). Because of their potential irreversibility (and images, audio or video files in some well-known encod- the resulting potential inability to recover a usable in- ings (e.g., HTML, JPEG, MP3, and RealMedia, respec- stance or variant without additional out-of-band infor- tively), and no processing beyond that which is intrinsic mation), entities are not suitable for conventional shared to that encoding is needed to render the variant to the caching. appropriate output device(s) or present it to the targeted Another distinction between an instance and an en- application logic. tity is that an instance is an end-to-end object from the application's perspective; upon successful completion Instances An instance is a variant with zero or more of an HTTP transaction, the client and the origin server content-codings applied to it. Content-codings are should (if the system has behaved properly) agree on transforms which preserve the wholeness or semantic the bytewise content of the instance in question. Enti- integrity of a variant/instance while altering the byte- ties, in contrast, are not necessarily end-to-end in this wise content of its presentation; for example: same sense, as proxies may interpret an entity and then ² Compression (e.g., gzip, compress, send a very different entity on to their next inbound deflate) or outbound peer (e.g., patching a hole in the cache's ² Wrapping content (encrypted, signed, or both) in a cryptographic envelope 2Cyclone coding was proposed as a media-coding, i.e., the vari- ² Integrity checks (e.g., MD5 checksums) ant would itself be a cyclone-coded object; see [2] for a critique of this design decision and motivation for classifying it as an instance- Because instances remain semantically whole rep- manipulation. resentations, they are suitable (in principle) for shared 3Compression is one of several operators also mentioned as a caches to store and use to answer subsequent requests. content-coding and a transfer-coding; intuitively, this is required be- cause a “compressed entity”, a “compressed instance”, and a “com- pressed message” have different meanings (inasmuch as entity, in- 1Our work builds upon the four-phase data model proposed by stance, and message have different meanings); e.g., a compressed Mogul et al [14, 15] as a refinement of RFC2616's three-phase model. delta must be handled differently than a compressed variant. copy of an instance with one byterange, then

Load more

  12

Copy Link