Unified User-Agent String
draft-karcz-uuas-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Mateusz Karcz | ||
| Last updated | 2021-11-24 (Latest revision 2014-11-10) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-karcz-uuas-01
Independent M. Karcz
Internet-Draft UKLO Tczew
Updates: 7231 (if approved) November 10, 2014
Intended status: Experimental
Expires: May 14, 2015
Unified User-Agent String
draft-karcz-uuas-01
Abstract
User-Agent is a HTTP request-header field. It contains information
about the user agent originating the request, which is often used by
servers to help identify the scope of reported interoperability
problems, to work around or tailor responses to avoid particular user
agent limitations, and for analytics regarding browser or operating
system use. Over the years contents of this field got complicated
and ambiguous. That was the reaction for sending altered version of
websites to web browsers other than popular ones. During the
development of the WWW, authors of the new web browsers used to
construct User-Agent strings similar to Netscape's one. Nowadays
contents of the User-Agent field are much longer than 15 years ago.
This Memo proposes the Uniform User-Agent String as a way to simplify
the User-Agent field contents, while maintaining the previous
possibility of their use.
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 May 14, 2015.
Karcz Expires May 14, 2015 [Page 1]
Internet-Draft Unified User-Agent String November 2014
Copyright Notice
Copyright (c) 2014 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.
This document may not be modified, and derivative works of it may not
be created, except to format it for publication as an RFC or to
translate it into languages other than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conformance . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Whitespaces . . . . . . . . . . . . . . . . . . . . . 3
2. Use of the User-Agent strings . . . . . . . . . . . . . . . . 3
3. Definition of Proposed Format . . . . . . . . . . . . . . . . 3
3.1. Standard String . . . . . . . . . . . . . . . . . . . . . 4
3.2. Regular String . . . . . . . . . . . . . . . . . . . . . 4
3.3. Web Browser String . . . . . . . . . . . . . . . . . . . 5
4. ABNF Definition of UUAS . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Nowadays User-Agent strings are long, complicated and often
ambiguous. (e.g. "Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux
i686; en) Opera 8.01" - it is Opera Browser, but it can be read as
Internet Explorer or Netscape Navigator.) This document specifies a
new, easy and clear format of Unified User-Agent String (UUAS), which
allows simple distinction between user agents, maintaining most of
the features of the existing solutions.
Karcz Expires May 14, 2015 [Page 2]
Internet-Draft Unified User-Agent String November 2014
1.1. Conformance
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].
1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. Section 4 contains a full syntax definition
of the Unified User-Agent String.
1.2.1. Whitespaces
This specification uses two rules to denote the use of linear
whitespace: OWS (optional whitespace) and RWS (required whitespace).
They are defined in Section 3.2.3 of [RFC7230].
2. Use of the User-Agent strings
Generally, the User-Agent header field was intended for statistical
purposes. However, in mid-90. during the "browser wars" data
provided by this field became used to alter the content of the
resources before sending them to the user, or even to prevent users
of particular browser the access to resources. To avoid these
protections, software vendors started to change their identifiers in
a way resembling User-Agent strings of the most popular browsers.
During the years it has made these identifiers much more complicated,
ambiguous and difficult to parse.
Nowadays User-Agent strings are still used for statistical purposes,
but also for avoiding limitations of particular implementations.
However, in modern browsers these limitations greatly decreased and
"user agent spoofing" is now unnecessary. Unfortunately, there are a
lot of websites still discriminating particular web browsers.
Unified User-Agent String is intended to propose a way for
simplifying, clarifying and standarizing the content of User-Agent
HTTP header field. Furthermore, if it becomes widespread, it will be
able to reduce the practice of "user agent spoofing" and
discrimination of particular groups of the Internet users.
3. Definition of Proposed Format
This document proposes a formal definition of three types of User-
Agent string: standard string, regular string and web browser string.
Karcz Expires May 14, 2015 [Page 3]
Internet-Draft Unified User-Agent String November 2014
User-Agent = uuas
uuas = standard-string / regular-string / browser-string
Standard string is intended to maintain backward compatibility with
existing implementions and it is the same simple format as defined in
[RFC7230].
Regular string introduces a degree of standardization making every
theoretical UUAS parser able to obtain information from it.
Web browser string is designed for modern graphical web browsers and
proposes a set of signatures, which should form together a clear and
unequivocal application identifier.
3.1. Standard String
The standard User-Agent string MUST be generated in conformance with
Section 5.5.3 of [RFC7231]. The standard User-Agent string consists
of one or more product identifiers, each followed by zero or more
comments (Section 3.2 of [RFC7230]), which together identify the user
agent software.
Standard string syntax definition:
standard-string = product *( RWS ( product / comment ) )
The product identifiers and comments SHOULD be listed in decreasing
order of their significance. Each of them consists of a name and
OPTIONAL version number.
In the standard string a sender SHOULD limit generated product
identifiers to what is necessary to identify the product; a sender
MUST NOT generate advertising or other nonessential information
within the product identifier. A sender SHOULD NOT place non-
version-related information in version number part of product
identifier. In the standard string successive versions of the same
product SHOULD differ only in the version part of the identifier.
Example:
CERN-LineMode/2.15 libwww/2.17b3
3.2. Regular String
Regular Unified User-Agent String is intended for request senders
other than graphical web browsers and general web crawlers. It MUST
provide a signature of the operating system or platform (eg. in case
of runtime environments) used to generate the request at the first
Karcz Expires May 14, 2015 [Page 4]
Internet-Draft Unified User-Agent String November 2014Nottingham Standards Track [Page 3]
RFC 5005 Feed Paging and Archiving September 2007
Example: Atom-formatted Complete Feed
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:fh="http://purl.org/syndication/history/1.0">
<title>NetMovies Queue</title>
<subtitle>The DVDs you'll receive next.</subtitle>
<link href="http://example.org/"/>
<fh:complete/>
<link rel="self"
href="http://netmovies.example.org/jdoe/queue/index.atom"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Casablanca</title>
<link href="http://netmovies.example.org/movies/Casablanca"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Here's looking at you, kid...</summary>
</entry>
</feed>
This specification does not address duplicate entries in complete
feeds.
3. Paged Feeds
A paged feed is a set of linked feed documents that together contain
the entries of a logical feed, without any guarantees about the
stability of each document's contents.
Paged feeds are lossy; that is, it is not possible to guarantee that
clients will be able to reconstruct the contents of the logical feed
at a particular time. Entries may be added or changed as the pages
of the feed are accessed, without the client becoming aware of them.
Therefore, clients SHOULD NOT present paged feeds as coherent or
complete, or make assumptions to that effect.
Paged feeds can be useful when the number of entries is very large,
infinite, or indeterminate. Clients can "page" through the feed,
only accessing a subset of the feed's entries as necessary.
Nottingham Standards Track [Page 4]
RFC 5005 Feed Paging and Archiving September 2007
For example, a search engine might make query results available as a
paged feed, so that queries with very large result sets do not
overwhelm the server, the network, or the client.
The feed documents in a paged feed are tied together with the
following link relations:
o "first" - A URI that refers to the furthest preceding document in
a series of documents.
o "last" - A URI that refers to the furthest following document in a
series of documents.
o "previous" - A URI that refers to the immediately preceding
document in a series of documents.
o "next" - A URI that refers to the immediately following document
in a series of documents.
Paged feed documents MUST have at least one of these link relations
present, and should contain as many as practical and applicable.
Example: Atom-formatted Paged Feed
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Example Feed</title>
<link href="http://example.org/"/>
<link rel="self" href="http://example.org/index.atom"/>
<link rel="next" href="http://example.org/index.atom?page=2"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>
</feed>
This specification does not address duplicate entries in paged feeds.
Nottingham Standards Track [Page 5]
RFC 5005 Feed Paging and Archiving September 2007
4. Archived Feeds
An archived feed is a set of feed documents that can be combined to
accurately reconstruct the entries of a logical feed.
Unlike paged feeds, archived feeds enable clients to do this without
losing entries. This is achieved by publishing a single subscription
document and (potentially) many archive documents.
A subscription document is a feed document that always contains the
most recently added or changed entries available in the logical feed.
Archive documents are feed documents that contain less recent entries
in the feed. The set of entries contained in an archive document
published at a particular URI SHOULD NOT change over time. Likewise,
the URI for a particular archive document SHOULD NOT change over
time.
The following link relations are used to tie subscription and
archived feeds together:
o "prev-archive" - A URI that refers to the immediately preceding
archive document.
o "next-archive" - A URI that refers to the immediately following
archive document.
o "current" - A URI that, when dereferenced, returns a feed document
containing the most recent entries in the feed.
Subscription documents and archive documents MUST have a "prev-
archive" link relation, unless there are no preceding archives
available. Archive documents SHOULD also have a "next-archive" link
relation, unless there are no following archives available.
Archive documents SHOULD indicate their associated subscription
documents using the "current" link relation.
Archive documents SHOULD also contain an fh:archive element in their
head sections to indicate that they are archives. fh:archive is an
empty element; this specification does not define any content for it.
Nottingham Standards Track [Page 6]
RFC 5005 Feed Paging and Archiving September 2007
Example: Atom-formatted Subscription Document
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Example Feed</title>
<link href="http://example.org/"/>
<link rel="self" href="http://example.org/index.atom"/>
<link rel="prev-archive"
href="http://example.org/2003/11/index.atom"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>
</feed>
Example: Atom-formatted Archive Document
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:fh="http://purl.org/syndication/history/1.0">
<title>Example Feed</title>
<link rel="current" href="http://example.org/index.atom"/>
<link rel="self" href="http://example.org/2003/11/index.atom"/>
<fh:archive/>
<link rel="prev-archive"
href="http://example.org/2003/10/index.atom"/>
<updated>2003-11-24T12:00:00Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Atom-Powered Robots Scheduled To Run Amok</title>
<link href="http://example.org/2003/11/24/robots_coming"/>
<id>urn:uuid:cdef5c6d5-gff8-4ebb-assa-80dwe44efkjo</id>
<updated>2003-11-24T12:00:00Z</updated>
<summary>Some text from an old, different entry.</summary>
</entry>
</feed>
Nottingham Standards Track [Page 7]
RFC 5005 Feed Paging and Archiving September 2007
In this example, the feed archives are split into monthly chunks, and
the subscription document points to the most recent complete archive
"http://example.org/2003/11/index.atom" using the "prev-archive"
relation. That document, in turn points to the previous archive
"http://example.org/2003/10/index.atom", and so on. Note that the
"2003/11" archive does not have a "next-archive" relation, because it
is the most recent complete archive; although another archive
("2003/12") may be under construction, it would be an error to link
to it before completion.
4.1. Publishing Archived Feeds
The requirement that archive documents be stable allows clients to
safely assume that if they have retrieved one in the past, it will
not meaningfully change in the future. As a result, if an archive
document's contents are changed, some clients may not become aware of
the changes.
Therefore, if a publisher requires a change to be visible to all
users (e.g., correcting factual errors), they should consider
publishing the revised entry in the subscription document, in
addition to (or instead of) the appropriate archive document.
Conversely, unimportant changes (e.g., spelling corrections) might be
only effected in archive documents.
Publishers SHOULD construct their feed documents in such a way as to
make duplicate removal unambiguous (see Section 4.2).
Publishers are not required to make all archive documents available;
they may refuse to serve (e.g., with HTTP status code 403 or 410) or
be unable to serve (e.g., with HTTP status code 404) an archive
document.
4.2. Consuming Archived Feeds
Typically, clients will "subscribe" to an archived feed by polling
the subscription document for recent changes. If a URI contained in
the prev-archive link relation has not been processed in the past,
the client can "catch up" with any missed entries by dereferencing it
and adding the contained entries to the logical feed. This process
should be repeated recursively until the client encounters a prev-
archive link relation that has been processed (the end of the archive
is indicated by a missing prev-archive link relation) or an error is
encountered.
If duplicate entries are found, clients SHOULD consider only the most
recently updated entry to be part of the logical feed. If duplicate
entries have the same update time-stamp, or no time-stamps are
Nottingham Standards Track [Page 8]
RFC 5005 Feed Paging and Archiving September 2007
available, the entry sourced from the most recently updated feed
document SHOULD replace all other duplicates of that entry.
In Atom-formatted archived feeds, two entries are duplicates if they
have the same atom:id element. The update time of an entry is
determined by its atom:updated element, and likewise the update time
of a feed document is determined by its feed-level atom:updated
element.
Clients SHOULD warn users when they are not able to reconstruct the
entire logical feed (e.g., by alerting the user that an archive
document is unavailable, or displaying pseudo-entries that inform the
user that some entries may be missing).
5. IANA Considerations
This specification defines the following new relations that have been
added to the Link Relations registry:
o Attribute Value: prev-archive
o Description: A URI that refers to the immediately
preceding archive document.
o Expected display characteristics: none
o Security considerations: See [RFC5005]
o Attribute Value: next-archive
o Description: A URI that refers to the immediately
following archive document.
o Expected display characteristics: none
o Security considerations: See [RFC5005]
Additionally, the "previous," "next", and "current" link relations
should be updated to refer to this document.
6. Security Considerations
Feeds using this mechanism have the same security considerations as
Atom [1]. Encryption and authentication security services can be
obtained by encrypting and/or signing the feed, as described in [1],
and may also be obtained through channel-based mechanisms (e.g., TLS
[6], HTTP authentication [7]) and/or transport (e.g., IPsec [8]).
Feeds using these mechanisms could be crafted in such a way as to
cause a client to initiate excessive (or even an unending sequence
of) network requests, causing denial of service (either to the
client, the target server, and/or intervening networks). Clients can
mitigate this risk by requiring user intervention after a certain
number of requests, or by limiting requests either according to a
Nottingham Standards Track [Page 9]
RFC 5005 Feed Paging and Archiving September 2007
hard limit, or with heuristics. Servers can mitigate this risk by
denying requests that they consider abusive (e.g., by closing the
connection or generating an error).
Clients should be mindful of resource limits when storing feed
documents. To reiterate, they are not required to always store or
reconstruct the feed when conforming to this specification; they only
need to inform the user when the reconstructed feed is not complete.
This specification does not define what it means when a logical
feed's component feed documents have different security mechanisms
applied.
7. References
7.1. Normative References
[1] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication
Format", RFC 4287, December 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML",
World Wide Web Consortium First Edition REC-xml-names-19990114,
January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[4] Tobin, R. and J. Cowan, "XML Information Set (Second Edition)",
World Wide Web Consortium Recommendation REC-xml-infoset-
20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
7.2. Informative References
[6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[7] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
Nottingham Standards Track [Page 10]
RFC 5005 Feed Paging and Archiving September 2007
[8] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[9] Winer, D., "RSS 2.0 Specification", 2005,
<http://www.rssboard.org/rss-specification>.
Nottingham Standards Track [Page 11]
RFC 5005 Feed Paging and Archiving September 2007
Appendix A. Acknowledgements
The author would like to thank the following people for their
contributions, comments, and help: Danny Ayers, Thomas Broyer, Lisa
Dusseault, Stefan Eissing, David Hall, Bill de Hora, Vidya Narayanan,
Aristotle Pagaltzis, John Panzer, Dave Pawson, Garrett Rooney, Robert
Sayre, James Snell, Henry Story, and Franklin Tse.
Any errors herein remain the author's, not theirs.
Appendix B. Use in RSS 2.0
As previously noted, while this specification's extensions are
described in terms of the Atom feed format, they are also useful in
similar formats. This informative appendix demonstrates how they can
be used in an RSS 2.0-formatted [9] feed.
In RSS 2.0-formatted feeds, two entries are duplicates if they have
the same guid element. The update time of an entry is not defined by
RSS 2.0, but the feed-level update time can be determined by the
lastBuildDate element, if present.
RSS 2.0-formatted Complete Feed
<?xml version="1.0&
position in the comment after the first product identifier. After
this signature the regular string MAY contain any comments and next
product identifiers. Only this information MUST be provided, because
this format is designed for cases, when the server does not need to
know the exact parameters of the application originating the request.
In such cases this string can be applicable in statistical purposes
or in adapting the server's response to capabilities of particular
software platforms (eg. for indicating the need for adding carriage
returns before the newlines).
Regular string syntax definition:
regular-string = product RWS "(" os [ sc 1*ctext ] ")"
*( RWS ( product / comment ) )
Regular Unified User-Agent Strings are syntactically compliant with
the standard definition.
Example:
Wget/1.11.1 (Red Hat modified)
3.3. Web Browser String
Web Browser User-Agent String is a format of this field-value
intended for identifying modern graphical web browsers, which are
compatible with HTML5, CSS3 or other modern web technologies. Web
browser string MUST contain "Mozilla/5.0" tag at the beginning for
historical reasons. This helps avoid the recognition of browsers as
very old ones. Web Browser UUAS MUST also contain "Gecko" tag. This
can avoid delivering impaired versions of websites to modern but not
Gecko-based client applications. It is also in conformance with
Section 6.6.1.1 of [W3C.REC-html5-20141028].
Web browser string syntax definition:
browser-string = Mozilla-tag
RWS "(" *( signature sc ) os
*( sc signature ) [ sc language ]
*( sc signature ) [ sc rvtag ] ")"
RWS Gecko-string
*( RWS ( product / comment ) )
Like regular string, Web Browser Unified User-Agent String MUST
provide information about software platform. Fields contained
between brakets (comments) SHOULD be separated by semicolons with
optional space. Application MAY also include language tag in its
Karcz Expires May 14, 2015 [Page 5]
Internet-Draft Unified User-Agent String November 2014
User-Agent string. Then it MUST be a Language-Tag in accordance with
[RFC5646].
Due to the fact that the application originating the request cannot
provide its version info in the first product identifier, it SHOULD
place its version number in the separate revision tag.
Of course, a sender can add to the string any valid product
identifiers and comments, but this Memo is intended to simplify and
clarify this element of the protocol. In the web browser string
there MUST be at least one signature allowing to identify particular
client application product. Also the order of platform, language and
revision signatures MUST NOT be changed.
This type of UUAS SHOULD be also used by general web crawlers. It
can help avoid certain unfair practices relying on delivering other
resources to web browsers, other to web crawlers.
Example:
Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
Karcz Expires May 14, 2015 [Page 6]
Internet-Draft Unified User-Agent String November 2014
4. ABNF Definition of UUAS
; Unified User-Agent String general definition
User-Agent = uuas
uuas = standard-string / regular-string / browser-string
; Standard string, as described in [RFC7231]
standard-string = product *( RWS ( product / comment ) )
; Regular string, recommended for non-browsers
regular-string = product RWS "(" os [ sc 1*ctext ] ")"
*( RWS ( product / comment ) )
; String recommended for web browsers and crawlers
browser-string = Mozilla-tag
RWS "(" *( signature sc ) os
*( sc signature ) [ sc language ]
*( sc signature ) [ sc rvtag ] ")"
RWS Gecko-string
*( RWS ( product / comment ) )
; Tags and signatures definitions
signature = product / 1*schar
os = 1*schar
language = <Language-Tag, see [RFC5646], Section 2.1>
rvtag = "rv:" OWS token
Mozilla-tag = "Mozilla/5.0"
Gecko-string = Gecko-tag
/ ( product RWS "(" *ctext
RWS Gecko-tag [ RWS 1*ctext ] ")" )
Gecko-tag = ["like "] "Gecko" ["/20100101"]
; Additional definitions
product = <product, see [RFC7231], Section 5.5.3>
comment = <comment, see [RFC7230], Section 3.2.6>
ctext = <ctext, see [RFC7230], Section 3.2.6>
schar = tchar / HTAB / SP / obs-text
token = <token, see [RFC7230], Section 3.2.6>
tchar = <tchar, see [RFC7230], Section 3.2.6>
obs-text = <obs-text, see [RFC7230], Section 3.2.6>
sc = ";" OWS
OWS = <OWS, see [RFC7230], Section 3.2.3>
RWS = <RWS, see [RFC7230], Section 3.2.3>
Karcz Expires May 14, 2015 [Page 7]
Internet-Draft Unified User-Agent String November 2014
5. Security Considerations
Implementations are encouraged not to use the product tokens of other
implementations in order to declare compatibility or identity with
them beyond the scope prescribed in this document, as this
circumvents the purpose of the User-Agent field.
A user agent SHOULD NOT generate a User-Agent field containing
needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly detailed User-Agent strings
increase request latency and the risk of a user being identified
against their wishes. In theory, this can make it easier for an
attacker to exploit known security holes; in practice, attackers tend
to try all potential holes regardless of the software being used.
But when User-Agent string is combined with other characteristics of
the application, particularly if the client application sends
excessive details about the user's system or extensions, the risk of
successful attack gets higher.
As User-Agent strings are text data, they can be used to carry out
attacks by causing buffer overfows or changing formatting strings.
Implementers should secure their applications against such practices.
Data provided by User-Agent header field can be used to discriminate
the users of particular client applications by preventing them
accessing the requested resources or replacing them with false ones.
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgments
I would like to thank my English teacher, who devoted her time to
conduct a linguistic revision of this Memo.
8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", RFC 5646, September 2009.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, STD 68, January 2008.
Karcz Expires May 14, 2015 [Page 8]
Internet-Draft Unified User-Agent String November 2014
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[W3C.REC-html5-20141028]
Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle
Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", World
Wide Web Consortium Recommendation REC-html5-20141028,
October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028/>.
Author's Address
Mateusz Karcz
Uniwersyteckie Katolickie Liceum Ogolnoksztalcace w Tczewie
6 Wodna Street
Tczew, PM 83-100
PL
Email: mateusz.karcz(at)interia.eu
Karcz Expires May 14, 2015 [Page 9]