![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changes between Version 6 and Version 7 of Ticket #502
- Timestamp:
- 31/10/13 15:27:32 (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #502 – Description
v6 v7 1 S. Moonesamy: 1 Major issues: None 2 2 3 This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations. 4 5 6 The document is well-written and clear. I did not verify the changes between this specification and RFC 2616 as the intended status is Proposed Standard. This specification can affect other specifications in the Applications Area as there are several specifications which are built upon HTTP. 7 8 9 Major issues: None 3 ---- 10 4 11 5 Minor issues: … … 17 11 The first RFC 2119 requirement (see above) states that the intermediary has to send its own HTTP-version while the second RFC 2119 requirement prohibits the intermediary from blindly forwarding the first line of the HTTP message. The intent of the first requirement seems clear to me. I suggest having the second requirement as clarifying text instead of a RFC 2119 requirement. 18 12 13 ---- 19 14 20 15 "A client SHOULD send a request version equal to the highest version to which the client is conformant and whose major version is no higher than the highest version supported by the server, if this is known." … … 22 17 The client would have to track the version supported by the server once it knows that information. A server can be one or more HTTP implementations. In practice these implementations will likely support HTTP 1.1. I'll list the "and whose major version is no higher than the highest version supported ..." as an issue. Is the intent to ensure that the client can work with HTTP 2.0? 23 18 19 ---- 24 20 25 21 "A server MAY send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's request." 26 22 27 23 Why is this a RFC 2119 "may"? 24 25 ---- 28 26 29 27 In Section 5.7: … … 33 31 I don't understand why an intermediary would forward a message to itself. Please note that I do not consider this prohibition as an issue. 34 32 33 ---- 35 34 36 35 In Section 6.1: … … 40 39 I am flagging the usage of a requirement followed by the "must ignore" requirement as an issue as the "in other words" suggest that it is a clarification of the first requirement. 41 40 41 ---- 42 42 43 43 In Section 6.4 … … 47 47 There is an explanation about why a specific number is not included for this recommendation in the paragraphs following the above text. I read Issue #131. I don't see any discussion of the tradeoffs in Section 6.4. The is a note about servers may reject an excessive number of connections from a client if they deem that it is abusive. 48 48 49 ---- 49 50 50 51 ~~The HTTP Transfer Coding namespace (Section 8.4) is currently "First Come First Served". The new registration procedure required IETF Review. What is the reason for the change?~~ -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0356.html 51 52 53 ---- 52 54 53 55 ~~In Section 8.5.1:~~ … … 61 63 ~~I suggest using plain English instead of RFC 2119 key words for the above (and for the rest of the text in Section 8.5.1).~~ - see #509 62 64 65 ---- 63 66 64 67 Nits: … … 66 69 ~~For Section 8.1, the Message Header Field Names registry is at http://www.iana.org/assignments/message-headers/~~ [2435] 67 70 68 69 71 ~~For Section 8.2, the URI Schemes registry is at http://www.iana.org/assignments/uri-schemes/~~ [2435] 70 71 72 72 73 ~~In Section 8.4, the RFC 2119 key words are not needed as that section is about a procedure for registration. Plain English is usually clear enough.~~ - see #509
