Network Working Group M.Lai Internet Draft C.Jian Intended status: Standards Track R.Trace Expires: March 2014 Microsoft Corporation September 13, 2013 HTTP/2.0 Protocol Test draft-trace-httpbis-http2-test-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 November, 2013. Copyright Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Lai, Jian, Trace, et. al. [Page 1] Internet-Draft HTTP/2.0 Testing May 2013 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. Abstract This document suggests guidance and principles for testing HTTP/2.0 implementations. Goals are to improve the HTTP/2.0 specification by mitigating the potential ambiguity of the protocol specification and improving interoperability of its implementations. Table of Contents 1. Scope and Goals................................................3 1.1. Requirements Language.....................................3 2. Test Framework and Scenarios...................................4 2.1. Cross-Platform Support....................................4 2.2. Test Areas................................................4 2.2.1. Upgrade..............................................4 2.2.2. Framing..............................................4 2.2.3. Flow Control.........................................4 2.2.4. Streams and Multiplexing.............................4 2.2.5. Header Compression...................................4 2.2.6. Connection Management................................4 2.2.7. Stream Prioritization................................4 2.2.8. Authentication.......................................4 2.2.9. SSL Negotiation......................................4 2.2.10. Proxies.............................................4 2.2.11. Server Push.........................................4 2.2.12. Use of TLS..........................................4 2.3. Test Results..............................................4 2.4. Test Organization.........................................5 2.5. Reliability...............................................5 2.6. Diagnosis Ability.........................................5 2.7. Ease of Execution.........................................5 2.8. Extensibility.............................................5 3. Security Considerations........................................6 4. IANA Considerations............................................6 5. Acknowledgments................................................6 6. References.....................................................6 6.1. Normative References......................................6 Lai, Jian, Trace, et. al. [Page 2] Internet-Draft HTTP/2.0 Testing May 2013 6.2. Informative References....................................6 1. Scope and Goals The scope of this document is to describe test framework and scenarios for client and server HTTP/2.0 implementations, primarily focusing on protocol compliance testing. Specific goals are: - Validate compliance with the HTTP/2.0 specification. Testing scenarios are derived from the protocol specification to ensure that implementations comply with all the "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT" terms. - Assure consistency in interpretation of the HTTP/2.0 specification. Behaviors and responses are consistent among each implementations and expected functionalities and outcomes are the same across. - Improve the HTTP/2.0 specification. Uncover unclear terms or gaps in the protocol specification during test development. Interpretation of test results may provide insight to potential specification issues. Propose appropriate fix based on the issues to enhance the HTTP/2.0 Protocol usability. Areas that are out of scope: - Security testing - Performance testing - Stress testing - Interoperability testing with real world web sites 1.1. Requirements Language 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 RFC 2119 [RFC2119]. Lai, Jian, Trace, et. al. [Page 3] Internet-Draft HTTP/2.0 Testing May 2013 2. Test Framework and Scenarios 2.1. Cross-Platform Support - Tests can be executed cross-platforms with consistent results. A consistent way of conveying results so that cross platform result carries the same meaning. - Tests are written with platform-independent programming language (for example, C/C++, Python) 2.2. Test Areas Test protocol compliance in terms of behaviors, boundary values, and error handling with interactions between client/server and intermediates. 2.2.1. Upgrade 2.2.2. Framing 2.2.3. Flow Control 2.2.4. Streams and Multiplexing 2.2.5. Header Compression 2.2.6. Connection Management 2.2.7. Stream Prioritization 2.2.8. Authentication 2.2.9. SSL Negotiation 2.2.10. Proxies 2.2.11. Server Push 2.2.12. Use of TLS 2.3. Test Results Pass/Fail test results strictly follows standards of protocol. - Behaviors that violate the "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT" terms of the HTTP/2.0 protocol will fail the tests Lai, Jian, Trace, et. al. [Page 4] Internet-Draft HTTP/2.0 Testing May 2013 - Error handling results with side effects (i.e. crashes) will fail the tests - Client/server which do not tolerate peers that follow "SHOULD", "RECOMMENDED", "MAY" behaviors will fail the tests 2.4. Test Organization - Test cases should be logically structured and well grouped. Supports test selection based on feature area, for example, server push, upgrade, proxy, etc. - Each test case must provide concrete descriptions and references to the IETF protocols - Test cases should identify which version it supports, for example, HTTP-draft-06/2.0, HTTP/2.0, etc - Test case name should be related to test scenarios and able to identify client/server side test 2.5. Reliability - Test cases should clean up and maintain the same environment after execution - Test cases yield the same results over time consistently 2.6. Diagnosis Ability - Test framework should support standard logging for after-test analysis - Logging should have different levels, for example, error level for protocol violation, warning level for potential interoperability problems, trace level for debug - Logging should report corresponding error code returned during testing 2.7. Ease of Execution Test framework can be automated through command line tools, nice to have UIs. 2.8. Extensibility Test framework has modular structure and extensible for shared development. It can be added by different Lai, Jian, Trace, et. al. [Page 5] Internet-Draft HTTP/2.0 Testing May 2013 vendors/companies/organizations, that is, different people can collaborate on different test areas. 3. Security Considerations None. 4. IANA Considerations None. 5. Acknowledgments This document was prepared using 2-Word-v2.0.template.doc. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-httpbis-http2] Belshe, M., Peon, R., Thomson, M., and A. Melnikov, "Hypertext Transfer Protocol version 2.0", draft-ietf- httpbis-http2 (work in progress), August 2013. 6.2. Informative References None. Author's Addresses Michelle Lai Microsoft Corporation Email: miclai@microsoft.com Lai, Jian, Trace, et. al. [Page 6] Internet-Draft HTTP/2.0 Testing May 2013 Changshu Jian Microsoft Corporation Email: ChangJia@microsoft.com Rob Trace Microsoft Corporation Email: Rob.Trace@microsoft.com Lai, Jian, Trace, et. al. [Page 7]