1 / 15

HTTP Extension Framework

HTTP Extension Framework. Name: Qin Zhao Id: 102906. This is designed to address the tension between private agreement and public specification. It is designed to accommodate dynamic extension of HTTP clients and servers by software components. Why is HTTP Extension Framework?.

Download Presentation

HTTP Extension Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. HTTP Extension Framework Name: Qin Zhao Id: 102906

  2. This is designed to address the tension between private agreement and public specification. It is designed to accommodate dynamic extension of HTTP clients and servers by software components. Why is HTTP Extension Framework?

  3. Notational Conventions This specification uses the same notational conventions and basic parsing constructs as usual Some particular BNF constructs like “token”, “quoted-string”, “Request-line”, “field-name”, and “absoluteURI” are to be interpreted Some key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted How to?

  4. And the more generic term URI is used throughout the specification An extension declaration can be used to indicate that an extension has been applied to a message and possibly to reserve a part of the header namespace identified by a header field prefix How to?

  5. This specification does not define any ramifications of applying an extension to a message nor whether two extensions can or cannot logically coexist within the same message How to?

  6. An extension is identified by an absolute, globally unique URI or a field-name. A field-name MUST specify a header field uniquely defined in an IETF Standards Track. A URI can unambiguously be distinguished from a field-name by the presence of a colon (":") How to?

  7. The header-prefix is a dynamically generated string Header field prefixes allow an extension declaration to dynamically reserve subspace of the header space in a protocol message in order to prevent header field name clashes and to allow multiple declarations using the same extension to be applied to the same message without conflicting About Header Field Prefixes

  8. Agent MUST NOT reuse header-prefix values in the same message unless explicitly allowed by the extension Clients should be as consistent as possible when generating header-prefix values as a function of the request extension declaration About Header Field Prefixes

  9. mandatory extension declaration It indicates that the ultimate recipient MUST consult and adhere to the rules given by the extension when processing the message or reporting the error optional extension declaration It indicates that the ultimate recipient May consult and adhere to the rules given by the extension when processing the message, or ignore the extension declaration completely Two types of extension declaration strength

  10. End-to-End Extension End-to-end declarations MUST be transmitted to the ultimate recipient of the declaration Hop-by-Hop Extension These declarations are meaningful only for a single HTTP connection Two types of Extensions

  11. While the protocol extension definition should be published at the extension identifier, the only absolute requirement is that extension identifiers MUST be globally unique identifiers, and that distinct names be used for distinct semantics An application MUST NOT claim conformance with and extension that it does not recognize Publishing an Extension

  12. The association between the extension identifier and the specification might be made by distributing a specification, which references the extension identifier It is strongly recommended that the integrity and persistence of the extension identifier be maintained and kept unquestioned throughout the lifetime of the extension Publishing an Extension

  13. Some party designs and specifies an extension; the party assigns the extension a globally unique URI, and makes one or more representaions of the extension available at that address An HTTP client or server that implements this extension mechanism(it is called an agent) declares the use of the extension by referencing its URI in an extension declaration in an HTTP message Where to use?

  14. The HTTP application which the extension declaration is intended for (it is called the ultimate recipient) can deduce how to properly interpret the extended message based on the extension declaration. Where to use?

  15. Describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers and proxies So there is a more general concern about whether this document actually represents community consensus regarding the evolution of HTTP Summary

More Related