RFC 6694 INFORMATIONAL URI · BROWSERS

The "about" URI Scheme

The about: address that browsers use to reach their own built-in pages, such as about:blank.

On rfc-editor.org ↗
PUBLISHED
August 2012
AUTHORS
S. Moonesamy
STREAM
IETF
SCHEME STATUS
Permanent
REGISTRY POLICY
First Come First Served
INITIAL TOKEN
blank
DOI
10.17487/RFC6694

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Internet Engineering Task Force (IETF)                 S. Moonesamy, Ed.
Request for Comments: 6694                                   August 2012
Category: Informational
ISSN: 2070-1721


                         The "about" URI Scheme

Abstract

   This document describes the "about" URI scheme, which is widely used
   by Web browsers and some other applications to designate access to
   their internal resources, such as settings, application information,
   hidden built-in functionality, and so on.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6694.

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.

Table of Contents

   1. Introduction ....................................................2
   2. URI Scheme Specification ........................................2
      2.1. URI Scheme Syntax ..........................................2
      2.2. URI Scheme Semantics .......................................3
           2.2.1. Well-Known "about" URIs .............................3
      2.3. Encoding Considerations ....................................3
   3. "about:blank" ...................................................3
   4. Security Considerations .........................................3
   5. IANA Considerations .............................................4
      5.1. URI Scheme Registration ....................................4
      5.2. A Registry for Well-Known Tokens ...........................5
           5.2.1. Registration Procedure ..............................5
   6. References ......................................................6
      6.1. Normative References .......................................6
      6.2. Informative References .....................................6
   Appendix A. Acknowledgments ........................................7

1.  Introduction

   This document describes the "about" Uniform Resource Identifier (URI)
   scheme.  The "about" URI scheme is currently widely used by Web
   browsers to designate access to their internal resources, such as
   settings, application information, and so-called "Easter eggs" (i.e.,
   a hidden feature or joke in an application).

2.  URI Scheme Specification

2.1.  URI Scheme Syntax

   The "about" URI syntactically conforms to the <about-uri> rule below,
   expressed using the Augmented Backus-Naur Form (ABNF) [RFC5234]:

     about-uri = "about:" about-token [ about-query ] [ about-fragment ]
     about-token = *pchar
     about-query = "?" query
     about-fragment = "#" fragment
     pchar     = <as specified in RFC 3986, Appendix A>
     query     = <as specified in RFC 3986, Appendix A>
     fragment  = <as specified in RFC 3986, Appendix A>

2.2.  URI Scheme Semantics

   The resource that is referenced by a particular "about" URI is
   denoted by the <about-token> part of the URI.  It is not a
   hierarchical element for a naming authority.  The <about-query> part
   specifies additional information about its handling and/or the
   information that should be returned by the resource referenced by
   the URI.

   It is impossible to specify a binding between all the possible tokens
   and the semantics of "about" URIs that would contain such tokens.
   Therefore, the resource referenced by the URI is generally considered
   to be specific to a Web browser implementation.

2.2.1.  Well-Known "about" URIs

   Some <about-token>s have been reserved, as the behavior of the
   resource that is referenced is well-known (well-known tokens).

   A well-known "about" URI is a URI that has a well-known token as its
   <about-token> part.  It is recommended that such URIs be handled in
   accordance with the specification referenced in the "about" URI
   Tokens registry (see Section 5.2).

   Well-known "about" URIs are intended to be registered when there is a
   need to codify the behavior of a particular <about-token>.

2.3.  Encoding Considerations

   "about" URIs are subject to encoding rules as defined in RFC 3986
   [RFC3986].

3.  "about:blank"

   This document defines one well-known token: "blank".  The
   "about:blank" URI refers to a resource represented in the browser by
   a blank page.

4.  Security Considerations

   Security considerations for URIs are discussed in Section 7 of
   RFC 3986 [RFC3986].  However, most of those provisions do not apply
   to the "about" URI scheme, as they are mainly scoped to schemes used
   in the Internet.

   "about" URIs can sometimes refer to sensitive information, such as
   user passwords stored in a cache, or parameters that, if changed,
   could affect a user's data.  The application therefore needs to
   ensure that the user's data is secured and no threats are imposed by
   "about" URIs.

5.  IANA Considerations

5.1.  URI Scheme Registration

   The "about" URI scheme has been registered in the "Permanent URI
   Schemes" registry.  The information below is provided according to
   the guidelines from RFC 4395 [RFC4395]:

      URI scheme name: about

      Status: Permanent

      URI scheme syntax: See Section 2.1 of RFC 6694.

      URI scheme semantics: See Section 2.2 of RFC 6694.

      URI scheme encoding considerations: See Section 2.3 of RFC 6694.

      Applications that use the scheme: "about" URIs are predominantly
         used by Web browsers.

      Security considerations: See Section 4 of RFC 6694.

      Contact: IETF Applications Area Directors
         <app-ads@tools.ietf.org>

      Author/Change controller: IESG <iesg@ietf.org> (on behalf of the
         IETF)

      References: See Section 6 of RFC 6694.

5.2.  A Registry for Well-Known Tokens

   This document creates the '"about" URI Tokens' registry.

   The registry entries consist of three fields: Token, Description, and
   Reference.  The Token field has to conform to <about-token>
   production as defined in Section 2.1.  The initial assignment is as
   follows:

   +--------------+------------------------------------+-------------+
   | Token        | Description                        | Reference   |
   +--------------+------------------------------------+-------------+
   | blank        | The about:blank URI references a   | RFC 6694    |
   |              | blank page.                        |             |
   +--------------+------------------------------------+-------------+

5.2.1.  Registration Procedure

   The registration policy for this registry is "First Come First
   Served", as described in RFC 5226 [RFC5226].  The registrant of the
   token should provide the information mentioned in the following
   registration template:

   o  Registered token:  The desired well-known token to be used in
      "about" URIs.

   o  Intended usage:  A short description of how "about" URIs with the
      registered token are handled, including information about the
      referenced resource.

   o  Contact/change controller:  Person (including contact information)
      authorized to change this registration.

   o  Specification:  A stable reference to a document that specifies
      the registered "about" URI.  The question of interoperability does
      not arise.  The key motivation is to have a reference to a
      specification documenting well-known behavior of the "about" URI
      in Web browsers.  As a rule of thumb, if the behavior is common to
      two or more Web browser implementations, it can be considered
      well-known.  An existing assignment may be duplicated if the
      registered token is used in more than one Web browser
      implementation.

   The following is a template for the "blank" token:

   o  Registered token:  blank

   o  Intended usage:  The about:blank URI references a blank page.

   o  Contact/change controller:  IESG <iesg@ietf.org> (on behalf of the
      IETF).

   o  Specification:  RFC 6694

6.  References

6.1.  Normative References

   [RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
               Resource Identifier (URI): Generic Syntax", STD 66,
               RFC 3986, January 2005.

   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
               May 2008.

   [RFC5234]   Crocker, D., Ed., and P. Overell, "Augmented BNF for
               Syntax Specifications: ABNF", STD 68, RFC 5234,
               January 2008.

6.2.  Informative References

   [RFC4395]   Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
               Registration Procedures for New URI Schemes", BCP 35,
               RFC 4395, February 2006.

Appendix A.  Acknowledgments

   This document was formed from a previous draft document initially
   authored by Lachlan Hunt and Joseph Holsten.  Additionally, the
   contributions of Frank Ellermann and Alexey Melnikov are gratefully
   acknowledged.  Barry Leiba and Murray Kucherawy deserve special
   credit for providing a great amount of text that was used in this
   document.

   Lachlan Hunt and Mykyta Yevstifeyev edited previous versions of this
   document.  Tim Bray and John Klensin provided suggestions about how
   to improve the document.

Author's Address

   S. Moonesamy (editor)
   76 Ylang Ylang Avenue
   Quatre Bornes
   Mauritius

   EMail: sm+ietf@elandsys.com

AI ELI5

On this page
PROBLEMWeb browsers and some other applications already used about: addresses for their settings, application information and hidden features, but the scheme was never written down or registered.
MECHANISMThe RFC defines the syntax of about: URIs in ABNF, says the part after the colon names a browser-specific resource, registers the scheme as Permanent, and creates an IANA registry of well-known tokens with blank as the first entry.
STATUS TODAYabout: URIs are mostly specific to each browser, and only behavior shared by two or more browsers is meant to be registered. The RFC is Informational.

§1What the about Scheme Is For

RFC 6694 describes the about Uniform Resource Identifier (URI) scheme. Web browsers use it to point to their own internal resources, such as settings, application information and so-called Easter eggs, meaning a hidden feature or joke in an application.

The scheme was already widely used when the RFC was written. The document records it and registers it, so that it has a proper definition.

Browsers have secret doors to their own settings and surprises. This memo writes down how those doors are named.

§2.1Syntax of an about URI

An about URI is written with ABNF as the literal about:, followed by an about-token, then an optional about-query (introduced by a question mark) and an optional about-fragment (introduced by a number sign). The token is zero or more pchar characters, and the query and fragment rules come from RFC 3986, Appendix A.

Encoding follows the rules of RFC 3986.

An about address is the word about, a colon, then a name, and sometimes a question or a bookmark at the end.

ABNF FROM SECTION 2.1
about URI syntax
about-uri = "about:" about-token [ about-query ] [ about-fragment ]
about-token = *pchar
about-query = "?" query
about-fragment = "#" fragment

§2.2Meaning and Well-Known Tokens

The about-token names the resource. It is not a hierarchical naming authority. The query part gives extra information about handling or about what the resource should return.

The RFC says no binding can be specified between all possible tokens and their meanings, so the resource is generally considered specific to a Web browser implementation. Some tokens are well-known because their behavior is common. It is recommended that such URIs be handled as the specification listed in the registry says.

This document defines one well-known token, blank. The URI about:blank refers to a blank page in the browser.

Most of the names only mean something inside one browser. The one name every browser agrees on is blank, which shows an empty page.

§4Security Considerations

Most of the URI security provisions in RFC 3986 do not apply, because they are mainly scoped to schemes used in the Internet.

The RFC warns that about URIs can sometimes refer to sensitive information, such as user passwords stored in a cache, or parameters that, if changed, could affect a user's data. The application therefore needs to ensure that the user's data is secured and that about URIs impose no threats.

Some of the browser's private rooms hold things like saved passwords, so the browser must keep those doors safely locked.

§5Registrations with IANA

The about scheme is registered in the Permanent URI Schemes registry. The registration names the IETF Applications Area Directors as contact and the IESG as change controller, and says the scheme is predominantly used by Web browsers.

The RFC also creates the about URI Tokens registry with three fields: Token, Description and Reference. The policy is First Come First Served. A registrant gives the token, its intended usage, a contact and a stable specification. As a rule of thumb, behavior common to two or more Web browser implementations can be considered well-known. The initial entry is blank.

There is now an official list of the shared names. Anyone can add a name if at least two browsers already treat it the same way.

§6References