Changes between Version 3 and Version 4 of Ticket #502


Ignore:
Timestamp:
28/10/13 15:40:17 (6 years ago)
Author:
julian.reschke@…
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #502 – Description

    v3 v4  
    1313In Section 2.6:
    1414
    15   "Intermediaries that process HTTP messages (i.e., all intermediaries
    16    other than those acting as tunnels) MUST send their own HTTP-version
    17    in forwarded messages.  In other words, they MUST NOT blindly forward
    18    the first line of an HTTP message without ensuring that the protocol
    19    version in that message matches a version to which that intermediary
    20    is conformant for both the receiving and sending of messages."
     15  "Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version in forwarded messages.  In other words, they MUST NOT blindly forward the first line of an HTTP message without ensuring that the protocol version in that message matches a version to which that intermediary is conformant for both the receiving and sending of messages."
    2116
    2217The 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.
    2318
    2419
    25   "A client SHOULD send a request version equal to the highest version
    26    to which the client is conformant and whose major version is no
    27    higher than the highest version supported by the server, if this is
    28    known."
     20  "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."
    2921
    3022The 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?
    3123
    3224
    33   "A server MAY send a 505 (HTTP Version Not Supported) response if
    34   it cannot send a response using the major version used in the
    35   client's request."
     25  "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."
    3626
    3727Why is this a RFC 2119 "may"?
     
    3929In Section 5.7:
    4030
    41   "An intermediary MUST NOT forward a message to itself unless it is
    42    protected from an infinite request loop.  In general, an intermediary
    43    ought to recognize its own server names, including any aliases, local
    44    variations, or literal IP addresses, and respond to such requests
    45    directly."
     31  "An intermediary MUST NOT forward a message to itself unless it is protected from an infinite request loop.  In general, an intermediary ought to recognize its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly."
    4632
    4733I don't understand why an intermediary would forward a message to itself. Please note that I do not consider this prohibition as an issue.
     
    5036In Section 6.1:
    5137
    52   "Recipients that trigger certain connection behavior based on the
    53    presence of connection options MUST do so based on the presence
    54    of the connection-option rather than only the presence of the
    55    optional header field.  In other words, if the connection option
    56    is received as a header field but not indicated within the
    57    Connection field-value, then the recipient MUST ignore the
    58    connection-specific header field because it has likely been
    59    forwarded by an intermediary that is only partially conformant.
     38  "Recipients that trigger certain connection behavior based on the presence of connection options MUST do so based on the presence of the connection-option rather than only the presence of the   optional header field.  In other words, if the connection option is received as a header field but not indicated within the Connection field-value, then the recipient MUST ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially conformant.
    6039
    6140I 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.
     
    6443In Section 6.4
    6544
    66   "A client SHOULD limit the number of simultaneous open connections
    67    that it maintains to a given server."
     45  "A client SHOULD limit the number of simultaneous open connections that it maintains to a given server."
    6846
    6947There 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.
     
    7553In Section 8.5.1:
    7654
    77   'The registration SHOULD name a set of expected "protocol-version"
    78    tokens associated with that token at the time of registration.'
     55  'The registration SHOULD name a set of expected "protocol-version" tokens associated with that token at the time of registration.'
    7956
    8057Why is this a RFC 2119 "should"?
    8158
    82   "The IESG MAY reassign responsibility for a protocol token.  This
    83    will normally only be used in the case when a responsible party
    84    cannot be contacted."
     59  "The IESG MAY reassign responsibility for a protocol token.  This will normally only be used in the case when a responsible party cannot be contacted."
    8560
    8661I 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).