Site-Wide HTTP Headers
draft-nottingham-site-wide-headers-01

Document Type Active Internet-Draft (individual)
Last updated 2016-11-23
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      M. Nottingham
Internet-Draft                                         November 24, 2016
Intended status: Standards Track
Expires: May 28, 2017

                         Site-Wide HTTP Headers
                 draft-nottingham-site-wide-headers-01

Abstract

   This document specifies an alternative way for Web sites to send HTTP
   response header fields that apply to an entire origin, to improve
   efficiency.

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 28, 2017.

Copyright Notice

   Copyright (c) 2016 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.

Nottingham                Expires May 28, 2017                  [Page 1]
Internet-Draft           Site-Wide HTTP Headers            November 2016

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Selecting Site-Wide Headers . . . . . . . . . . . . . . .   3
     1.2.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Notational Conventions  . . . . . . . . . . . . . . . . .   5
   2.  Server Operation  . . . . . . . . . . . . . . . . . . . . . .   5
   3.  User Agent Operation  . . . . . . . . . . . . . . . . . . . .   6
     3.1.  The "SH" HTTP Request Header Field  . . . . . . . . . . .   6
     3.2.  The "HS" HTTP Response Header Field . . . . . . . . . . .   7
   4.  The "site-headers" well-known URI . . . . . . . . . . . . . .   7
     4.1.  The "text/site-headers" Media Type  . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     6.1.  Injecting Headers . . . . . . . . . . . . . . . . . . . .   8
     6.2.  Differing Views of Headers  . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   HTTP response headers are being used for an increasing amount of
   metadata that applies to an entire Web site (i.e., the entire origin,
   as per [RFC6454]).

   For example, "Strict-Transport-Security" [RFC6797] and "Public-Key-
   Pins" [RFC7469] both define headers that are explicitly scoped to an
   entire origin, and number of similar headers are under consideration.

   Likewise, some HTTP header fields only sensibly have a single value
   per origin; for example, "Server".

   Furthermore, some headers are used uniformly across an origin.  For
   example, a site might have a homogenous "Content-Security-Policy"
   [W3C.CR-CSP2-20150721] header.

   HTTP/2's HPACK [RFC7541] header compression mechanism was designed to
   reduce bandwidth usage for often-repeated headers, both in responses
   and requests.  However, it limits the amount of compression contents
   usable for a connection (by default, 4K), and some sites are
   beginning to exceed this limit, thereby reducing the efficiency of
   HPACK itself.

   For example, it is not uncommon for a CSP response header field to
   exceed 1K (and has been observed to be greater than 3K on popular
   sites).  This forces site administrators to make an awkward choice;

Nottingham                Expires May 28, 2017                  [Page 2]
Show full document text