Skip to content

Instantly share code, notes, and snippets.

@guersam

guersam/gist:2a3d61d6429f62a43ee6

Last active August 29, 2015 14:03
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save guersam/2a3d61d6429f62a43ee6 to your computer and use it in GitHub Desktop.
Save guersam/2a3d61d6429f62a43ee6 to your computer and use it in GitHub Desktop.
Download ZIP
Changes from RFC2616 to RFC7230 ~ RFC7235
Raw
gistfile1.md

Changes from RFC2616 to RFC7230 ~ RFC7235

This document aggregates Changes from RFC(s) 2616 (and 2617) sections from RFC7230 to RFC7235, which supersede RFC2616. See Mark Nottingham's blog post for further background.

RFC7230 - HTTP/1.1: Message Syntax and Routing

  • HTTP's approach to error handling has been explained. (Section 2.5)

  • The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers have been restricted to single digits, due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (Section 2.6)

  • Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their transmission on the wire. (Section 2.7.1)

  • The HTTPS URI scheme is now defined by this specification; previously, it was done in Section2.4 of [RFC2818]. Furthermore, it implies end-to-end security. (Section 2.7.2)

  • HTTP messages can be (and often are) buffered by implementations; despite it sometimes being available as a stream, HTTP is fundamentally a message-oriented protocol. Minimum supported sizes for various protocol elements have been suggested, to improve interoperability. (Section 3)

  • Invalid whitespace around field-names is now required to be rejected, because accepting it represents a security vulnerability. The ABNF productions defining header fields now only list the field value. (Section 3.2)

  • Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed where specifically defined in the ABNF. (Section 3.2.3)

  • Header fields that span multiple lines ("line folding") are deprecated. (Section 3.2.4)

  • The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been clarified. The quoted-pair rule no longer allows escaping control characters other than HTAB. Non-US-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (Section 3.2.6)

  • Bogus Content-Length header fields are now required to be handled as errors by recipients. (Section 3.3.2)

  • The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven by methods or status codes) that affect it, and that new protocol elements cannot define such special cases. CONNECT is a new, special case in determining message body length. "multipart/byteranges" is no longer a way of determining message body length detection. (Section 3.3.3)

  • The "identity" transfer coding token has been removed. (Sections 3.3 and 4)

  • Chunk length does not include the count of the octets in the chunk header and trailer. Line folding in chunk extensions is disallowed. (Section 4.1)

  • The meaning of the "deflate" content coding has been clarified. (Section 4.2.2)

  • The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808. The asterisk-form of the request-target is only allowed with the OPTIONS method. (Section 5.3)

  • The term "Effective Request URI" has been introduced. (Section 5.5)

  • Gateways do not need to generate Via header fields anymore. (Section 5.7.1)

  • Exactly when "close" connection options have to be sent has been clarified. Also, "hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop in this specification doesn't exempt them. (Section 6.1)

  • The limit of two connections per server has been removed. An idempotent sequence of requests is no longer required to be retried.

  • The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. Also, some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (Section 6.3)

  • The semantics of the Upgrade header field is now defined in responses other than 101 (this was incorporated from [RFC2817]). Furthermore, the ordering in the field value is now significant. (Section 6.7)

  • Empty list elements in list productions (e.g., a list header field containing ", ,") have been deprecated. (Section 7)

  • Registration of Transfer Codings now requires IETF Review (Section 8.4)

RFC7231 - HTTP/1.1: Semantics and Content

  • The primary changes in this revision have been editorial in nature: extracting the messaging syntax and partitioning HTTP semantics into separate documents for the core features, conditional requests, partial requests, caching, and authentication. The conformance language has been revised to clearly target requirements and the terminology has been improved to distinguish payload from representations and representations from resources.

  • A new requirement has been added that semantics embedded in a URI be disabled when those semantics are inconsistent with the request method, since this is a common cause of interoperability failure. (Section 2)

  • An algorithm has been added for determining if a payload is associated with a specific identifier. (Section 3.1.4.1)

  • The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition says. Likewise, special treatment of ISO-8859-1 has been removed from the Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3)

  • The definition of Content-Location has been changed to no longer affect the base URI for resolving relative URI references, due to poor implementation support and the undesirable effect of potentially breaking relative links in content-negotiated resources. (Section 3.1.4.2)

  • To be consistent with the method-neutral parsing algorithm of [RFC7230], the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (Section 4.3.1)

  • Servers are no longer required to handle all Content-* header fields and use of Content-Range has been explicitly banned in PUT requests. (Section 4.3.4)

  • Definition of the CONNECT method has been moved from [RFC2817] to this specification. (Section 4.3.6)

  • The OPTIONS and TRACE request methods have been defined as being safe. (Section 4.3.7 and Section 4.3.8)

RFC7232 - HTTP/1.1: Conditional Requests

  • The definition of validator weakness has been expanded and clarified. (Section 2.1)

  • Weak entity-tags are now allowed in all requests except range requests. (Sections 2.1 and 3.2)

  • The ETag header field ABNF has been changed to not use quoted-string, thus avoiding escaping issues. (Section 2.3)

  • ETag is defined to provide an entity tag for the selected representation, thereby clarifying what it applies to in various situations (such as a PUT response). (Section 2.3)

  • The precedence for evaluation of conditional requests has been defined. (Section 6)

  • This specification now defines the Upgrade Token Registry, previously defined in Section7.2 of [RFC2817]. (Section 8.6)

  • The expectation to support HTTP/0.9 requests has been removed. (Appendix A)

  • Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged altogether. (Appendix A.1.2)

RFC7233 - HTTP/1.1: Range Requests

  • Servers are given more leeway in how they respond to a range request, in order to mitigate abuse by malicious (or just greedy) clients. (Section 3.1)

  • A weak validator cannot be used in a 206 response. (Section 4.1)

  • The Content-Range header field only has meaning when the status code explicitly defines its use. (Section 4.2)

  • This specification introduces a Range Unit Registry. (Section 5.1)

  • multipart/byteranges can consist of a single part. (Appendix A)

RFC7234 - HTTP/1.1: Caching

  • The specification has been substantially rewritten for clarity.

  • The conditions under which an authenticated response can be cached have been clarified. (Section 3.2)

  • New status codes can now define that caches are allowed to use heuristic freshness with them. Caches are now allowed to calculate heuristic freshness for URIs with query components. (Section 4.2.2)

  • The algorithm for calculating age is now less conservative. Caches are now required to handle dates with time zones as if they're invalid, because it's not possible to accurately guess. (Section 4.2.3)

  • The Content-Location response header field is no longer used to determine the appropriate response to use when validating. (Section 4.3)

  • The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now explicitly allows header-specific canonicalization when processing selecting header fields. (Section 4.1)

  • Requirements regarding denial-of-service attack avoidance when performing invalidation have been clarified. (Section 4.4)

  • Cache invalidation only occurs when a successful response is received. (Section 4.4)

  • Cache directives are explicitly defined to be case-insensitive. Handling of multiple instances of cache directives when only one is expected is now defined. (Section 5.2)

  • The "no-store" request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it and does not invalidate it. (Section 5.2.1.5)

  • The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; for example, "private=foo" is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified. (Section 5.2.2)

  • The "no-cache" response directive's meaning has been clarified. (Section 5.2.2.2)

  • The one-year limit on Expires header field values has been removed; instead, the reasoning for using a sensible value is given. (Section 5.3)

  • The Pragma header field is now only defined for backwards compatibility; future pragmas are deprecated. (Section 5.4)

  • Some requirements regarding production and processing of the Warning header fields have been relaxed, as it is not widely implemented. Furthermore, the Warning header field no longer uses RFC 2047 encoding, nor does it allow multiple languages, as these aspects were not implemented. (Section 5.5)

  • This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives. (Section 7.1 and Section 7.2)

RFC7235: HTTP/1.1: Authentication

  • The framework for HTTP Authentication is now defined by this document, rather than RFC 2617.

  • The "realm" parameter is no longer always required on challenges; consequently, the ABNF allows challenges without any auth parameters. (Section 2)

  • The "token68" alternative to auth-param lists has been added for consistency with legacy authentication schemes such as "Basic". (Section 2)

  • This specification introduces the Authentication Scheme Registry, along with considerations for new authentication schemes. (Section 5.1)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment