Network Working Group LJM. McSherry Internet-Draft December 4, 2012 Intended status: BCP Expires: June 7, 2013 HTTP User Agent Feature Identifiers draft-mcsherry-hafi-01 Abstract HTTP User Agent Feature Identifiers (HAFI, Hah-Fee) is a simple method for user agents, such as web browsers, to reveal the technologies that are supported by them. These technologies include items such as Cascading Style Sheets, and various versions of HTML. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 7, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. McSherry Expires June 7, 2013 [Page 1] Internet-Draft HAFI December 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. For User Agents . . . . . . . . . . . . . . . . . . . . . . 3 2.2. For Servers and Responders . . . . . . . . . . . . . . . . 4 3. Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. HTTP HAFI Header Example . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 McSherry Expires June 7, 2013 [Page 2] Internet-Draft HAFI December 2012 1. Introduction HTTP User Agent Feature Identifiers (HAFI, Hah-Fee) is a simple method for user agents, such as web browsers, to reveal the technologies that are supported by them. These technologies include items such as Cascading Style Sheets, and various versions of HTML. HAFI allows web developers to easily determine the technologies supported by user agents, and present content appropriate to those technologies. HAFI is intended to prevent having to maintain a database of User Agent strings in order to determine functionality. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Implementation Identifiers are composed of a 32-bit unsigned integer, each bit in this representing a technology. Identifiers are in a little-endian format, and setting a bit to high (one) shows that the technology is supported, while setting a bit to low (zero) shows that the technology is unsupported. 2.1. For User Agents Identifiers are transmitted to the server via HTTP request headers, using a header entitled "HAFI". This header will provide both the version of HAFI being adhered to, and the identifier itself. The format of the HAFI header is as shown below. The order of the attributes, "version" and "features", is unimportant, but user agents are required to include both attributes. HAFI: version=1.0; features=82 User agents should not misrepresent the technologies supported by them, and they should not add vendor-specific values to feature identifiers, as this would render HAFI pointless. User agents are also advised to set the value of reserved bits to low. McSherry Expires June 7, 2013 [Page 3] Internet-Draft HAFI December 2012 2.1.1. Notice on Listing CSS Support User agents should only list support for a version of CSS if the version is supported without vendor-specific prefixes. For example, the prefix used with Mozilla Firefox is "-moz-". If the user agent supports CSS features only through vendor-specific prefixes, the appropriate version of CSS should not be shown as supported in the identifier provided by the user agent. 2.2. For Servers and Responders When implementing HAFI into a server or responder, developers must include every version of HAFI to ensure backwards compatibility with older software that may not support the latest versions of HAFI. Servers and responders must not attempt to parse any bits that are listed as reserved in the version of HAFI presented by the user agent. While user agents are recommended not to set any reserved bits to high, there is no guarantee that all implementing user agents will do this. If the presented version of HAFI is a version that is newer than the most recent version implemented in a server or responder, servers and responders should attempt to parse identifiers with the most recent version available. If the presented version is invalid (e.g. "version=1-t!"), servers and responders should not attempt to parse the features, and are recommended to respond with the HTTP 400 status code (Bad Request). 3. Features Below is a table listing the features that can be represented in the current version of HAFI. Developers are reminded that features should be presented in a little-endian format, and that reserved bits should be set to low (zero). McSherry Expires June 7, 2013 [Page 4] Internet-Draft HAFI December 2012 +--------+--------------------------------+ | Bit(s) | Technology / Description | +--------+--------------------------------+ | 0 | Hypertext Markup Language 4.01 | | 1 | Hypertext Matkup Language 5 | | 2 | Cascading Style Sheets | | 3 | Cascading Style Sheets 2 | | 4 | Cascading Style Sheets 3 | | 5 | Cascading Style Sheets 4 | | 6 | ECMAScript / JavaScript | | 7 | HTML5 Geolocation | | 8 | HTML5 Video - Ogg Vorbis | | 9 | HTML5 Video - H.264 | | 10 | HTML5 Video - WebM | | 11 | HTML5 Canvas | | 12 | Secure Sockets Layer v2 | | 13 | Secure Sockets Layer v3 | | 14 | Transport Layer Security 1.0 | | 15 | Transport Layer Security 1.1 | | 16 | Transport Layer Security 1.2 | | 17 | HTTP Strict Transport Security | | 18 | Do Not Track (DNT) | | 19:31 | Reserved for Future Usage | +--------+--------------------------------+ It should be noted that, for identifiers such as Do Not Track, the value of that bit being set to high (one) does not indicate that the feature is enabled, only that the user agent supports it. 3.1. HTTP HAFI Header Example This section will provide an example of a HAFI header that can be used for reference. The example user agent supports the following technologies: HTML4.01, HTML5, CSS1+2+3, JavaScript, Geolocation, H.264 and WebM, SSLv3, and TLS 1.0 + 1.1. The features identifier in binary would be the following: 00000000 00000000 11100110 11011111 The example user agent is abiding by HAFI 1.0, and the identifier in binary will be converted to decimal for transmission, so the HAFI header sent by the user agent would be the following: HAFI: version=1.0; features=59103 McSherry Expires June 7, 2013 [Page 5] Internet-Draft HAFI December 2012 4. Security Considerations HAFI should not have any security implications, as it is simply a number and a version string being sent to a server. Rather, HAFI may improve security, in certain contexts. For example, if a client shows that it supports SSLv3 and TLS 1.0 whilst connecting over HTTPS, the server would be able to select a stream cipher over a block cipher, which would lower the likelihood of a BEAST attack on the client. 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Liam James McSherry Email: liamj.mcsherry@googlemail.com McSherry Expires June 7, 2013 [Page 6]