Network Working Group S. Harhalakis Internet-Draft TEI of Thessaloniki Intended status: Standards Track August 2007 Expires: February 2, 2008 Header Request for HTTP draft-sharhalakis-httphreq-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Harhalakis Expires February 2, 2008 [Page 1] Internet-Draft Header Request for HTTP August 2007 Abstract This document describes a method that extends HTTP to support optional on-demand headers as an addition to its dialogs. Any server side application using this method becomes able to request additional headers from conforming HTTP clients. It can also serve as an intermediate step for introducing new HTTP headers without placing the need for always exchanging them. An additional HTTP header is described and its ABNF description is provided. IANA is requested to extend its HTTP registry to support the 'on-demand' flag. IANA is also requested to provide support for header names that actually identify groups of headers. Harhalakis Expires February 2, 2008 [Page 2] Internet-Draft Header Request for HTTP August 2007 Discussion Discussion about this document takes place in http-wg mailing list (ietf-http-wg@w3.org). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Side effects . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Protocol definition . . . . . . . . . . . . . . . . . . . 6 2.1.1. Server side . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Client side . . . . . . . . . . . . . . . . . . . . . 6 2.1.3. Caching . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.4. Groups of headers . . . . . . . . . . . . . . . . . . 7 2.2. Header syntax . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Proxy considerations . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 3.1. Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Harhalakis Expires February 2, 2008 [Page 3] Internet-Draft Header Request for HTTP August 2007 1. Introduction 1.1. Purpose Web based applications are exploiting the HTTP protocol [RFC2616] to achieve better results and provide additional capabilities. Every now and then server side applications introduce additional requirements from HTTP clients in the form of new HTTP headers. Current HTTP specification requires that all newly introduced HTTP headers must always be exchanged, resulting in a worldwide traffic increase. Discussions regarding a new HTTP header proposal revealed that the need for optional on-demand headers actually exists. The HTTP protocol can be further extended to provide such a framework. This document addresses this need by describing a method and a HTTP header that allows server side applications to request additional headers from clients. This request does not place a requirement for HTTP clients and merely acts as a hint. By providing support for on-demand offering of headers from clients, the HTTP protocol can be easily enriched with additional headers that may provide additional functionality to the world wide web. The advancement comes from the ability of the community to test those newly introduced headers (that will be defined by future RFCs) without requiring that HTTP applications exchange them all of the time. 1.2. Side effects An interesting side effect of implementing this method is that handling of HTTP headers can be further formalized. HTTP clients (especially web browsers) can implement a standard framework that will allow users to manage on-demand headers that will be transmitted in the way cookies are handled. It is believed that it will increase user privacy and may allow the HTTP protocol to further scale. 1.3. Requirements 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]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements is said to be "conditionally compliant". Harhalakis Expires February 2, 2008 [Page 4] Internet-Draft Header Request for HTTP August 2007 1.4. Terminology This document uses the following terms: HTTP client Every client of the HTTP protocol. Commonly referred to as a web browser or a user agent. HTTP header A HTTP header as described in [RFC2616]. HTTP request A HTTP request from a HTTP client to a HTTP server. Header Request A list of headers that the client is required to provide. HRQ Acronym for 'Header ReQuest'. Header Group or Header-group A predefined group of headers. HG Acronym for 'Header Group'. HG Name A string that identifies a header-group and corresponds to more that one headers. HGN Acronym for 'Header Group Name'. The HTTP header specification of this document is presented in the augmented Backus-Naur Form that is described in [RFC2616]. Harhalakis Expires February 2, 2008 [Page 5] Internet-Draft Header Request for HTTP August 2007 2. Definition 2.1. Protocol definition 2.1.1. Server side Server side applications MAY use the Header Request (HRQ) header to request additional headers from HTTP clients. Those applications MUST NOT assume that clients will respond to their request nor that clients support the HRQ header. Server side MUST always send the same HRQ, even if some or all of the requested headers exist, to prevent the ping-pong effect. This means that a server side script that requests header H, MUST send the HRQ for header H even when that header is provided. A HRQ may request one or more headers. A HRQ MUST request at least one header. Multiple HRQs are allowed. This means that server side may provide multiple HRQ lines, each one requesting one or more headers. 2.1.2. Client side Client side applications MAY support the server side HRQ. Those clients MAY be willing to respond to the HRQ. Willing clients MAY perform an additional and almost identical HTTP request which will provide additional headers. An additional request MUST NOT be performed when there is no corresponding Vary header. This means that a client MUST NOT perform an additional request just to provide an on-demand HTTP header that is not mentioned in the Vary header. If an additional request is made, it MUST include at least one of the requested headers that was not already provided. HTTP clients don't need to provide all of the requested headers. The additional request SHOULD NOT be performed when doing form submission or a POST request. 2.1.3. Caching HRQ MAY include a Domain and Path parameter that have the semantics of [RFC2109]. Clients MAY cache per Domain/Path HRQ and automatically send the additional headers in future sessions without waiting for an HRQ. Clients MUST match all of Domain/Path information before sending any headers that are the result of cached HRQs. Clients SHOULD update their cache upon receipt of an HRQ. This ensures that they will not send on-demand headers that are not required any more for more than one requests. Clients that are sending an additional header because of an older HRQ that is no Harhalakis Expires February 2, 2008 [Page 6] Internet-Draft Header Request for HTTP August 2007 longer requested SHOULD stop sending it. Clients that detect a HRQ that can be further satisfied (partially or fully) MAY perform another request including the additional header(s). Clients MUST NOT perform an additional request just to not provide a header. This means that an additional request can be justified only when there is an additional header to transmit. 2.1.4. Groups of headers Documents that define on-demand headers (which are HRQ candidates) MAY group a number of them and provide a header-group (HG) name (HGN). When an HRQ requests for that HG using its HGN, the HTTP client MUST satisfy or ignore it as a whole. This means that the HTTP client MUST either send all of the headers that belong to the HG, or send none. HGNs share the same namespace with HTTP headers. This means that a name that identifies a HG (a HGN) cannot be used for a HTTP header and vice versa. HGNs SHALL only be used in HRQs. This means that a HGN will never be transmitted from the client side to the server side. Server side SHOULD NOT use a partially fullfilled HG request unless it is needed for backward compatibility (when a HG is updated to request for additional headers). 2.2. Header syntax For the purposes of this document the following HTTP header is defined: header-request = "Header-Request" ":" h-rq h-param h-rq = h-element *( "," h-element ) h-element = token h-param = *( ";" h-param-av ) h-param-av = "Domain" "=" value ; *1* / "Path" "=" value ; *1* / "Secure" ; *1* Where: h-element A header name or a HGN token A name as specified in [RFC2616]. Harhalakis Expires February 2, 2008 [Page 7] Internet-Draft Header Request for HTTP August 2007 value A value as defined in HTTP State Management Mechanism [RFC2109]. *1* Same semantics as in HTTP State Management Mechanism [RFC2109]. Usage of h-param is the same as in cookie-av described in [RFC2109]. Same grammar and semantics apply. 2.3. Proxy considerations HTTP proxy servers MUST NOT alter this information. Proxy behavior regarding the additional on-demand headers does not belong to the scope of this document. This will be defined by those header specifications. Some on-demand headers may be used to provide customized content while others may be used for other purposes. All requested headers that may result to different content need to be listed in a corresponding Vary header too. Since this is already handled by proxies, no further action is required. Harhalakis Expires February 2, 2008 [Page 8] Internet-Draft Header Request for HTTP August 2007 3. Security Considerations 3.1. Security Server side SHOULD NOT assume that a request for a HG will be fully satisfied by the client. Non conforming or malicious clients SHOULD be expected. Apart from that it is believed that the HRQ header does not introduce other security issues. 3.2. Privacy On-demand HTTP headers MAY concern user privacy. HTTP clients (and especially web browsers) SHOULD allow the user to controll the transmission of those headers. HTTP clients MAY allow the user to controll the transmission of other on-demand headers (that don't concern user privacy) too. It is advised that web browsers provide user settings similar to those of cookies to allow for complete user control. The exact security considerations of each on-demand header will be defined in the corresponding RFCs. This document just warns about the possible future needs. Harhalakis Expires February 2, 2008 [Page 9] Internet-Draft Header Request for HTTP August 2007 4. IANA Considerations This specification requires registration of a Message Header Field for HTTP [RFC3864]: Header field: Header-Request Applicable protocol: HTTP Status: Experimental Author/change controller: IETF (iesg@ietf.org) Internet Engineering Task Force Specification document: [ this document ] IANA must also add an attribute for newly introduced headers that will act as a hint for HTTP clients. This attribute will be named 'on-demand' and will act as a flag, identifying headers that should be sent after server side request. The possible values of this flag must be 'Yes' and 'No'. IANA is advised to set and keep this flag on newly introduced client side headers at least until their corresponding RFCs reach the 'Draft Standard' state. IANA is also advised not to remove this flag from headers that are not needed for a significant portion of the worldwide web traffic. IANA's motive regarding this attribute should be the worldwide bandwidth and resource conservation. For existing headers the 'on-demand' flag MUST be set to 'No' to provide backwards compatibility. IANA SHOULD request from authors of newly introduced headers to indicate the 'on-demand' status. Newly introduced headers that don't specify the on-demand flag state (either Yes or No) MUST be considered as having it set to 'No'. IANA must add a second attribute for existing and newly introduced headers that will distinguish common HTTP headers from HGNs. New Message Header Field for HTTP registrations MAY specify whether the requested header is a HGN or not. Header registration requests that do not specify this MUST be considered as common headers. It is DISCOURAGED to create a new registry because the HTTP headers and the HGNs share the same namespace. Harhalakis Expires February 2, 2008 [Page 10] Internet-Draft Header Request for HTTP August 2007 5. References 5.1. Normative [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. 5.2. Informative [I-D.rfc-editor-rfc2223bis] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08 (work in progress), July 2004. Harhalakis Expires February 2, 2008 [Page 11] Internet-Draft Header Request for HTTP August 2007 Author's Address Stefanos Harhalakis Technological Educational Institute of Thessaloniki Department of Information Technology Thessaloniki, Greece GR Email: v13@it.teithe.gr, v13@priest.com Harhalakis Expires February 2, 2008 [Page 12] Internet-Draft Header Request for HTTP August 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Harhalakis Expires February 2, 2008 [Page 13]