Skip to main content

HTTP Semantics
draft-ietf-httpbis-semantics-19

Revision differences

Document history

Date Rev. By Action
2024-01-26
19 Gunter Van de Velde Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review
2024-01-26
19 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2022-04-28
19 Mark Nottingham
2022-04-28
19 Mark Nottingham
2022-04-28
19 Mark Nottingham
2022-04-25
19 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-12-23
19 (System) RFC Editor state changed to AUTH48
2021-11-11
19 (System) RFC Editor state changed to RFC-EDITOR from REF
2021-10-26
19 (System) RFC Editor state changed to REF from EDIT
2021-10-06
19 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-10-05
19 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-10-05
19 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-10-05
19 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-10-05
19 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-10-04
19 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-10-04
19 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-10-04
19 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-10-04
19 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-10-04
19 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-10-04
19 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-10-01
19 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-09-30
19 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-09-20
19 Robert Sparks Rebuilt reference relations
2021-09-17
19 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-09-17
19 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-09-16
19 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2021-09-16
19 Tero Kivinen Assignment of request for Last Call review by SECDIR to Mališa Vučinić was marked no-response
2021-09-15
19 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-09-13
19 (System) RFC Editor state changed to EDIT
2021-09-13
19 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-09-13
19 (System) Announcement was received by RFC Editor
2021-09-13
19 (System) IANA Action state changed to In Progress
2021-09-13
19 Amy Vezza Downref to RFC 8446 approved by Last Call for draft-ietf-httpbis-semantics-19
2021-09-13
19 Amy Vezza Downref to RFC 7405 approved by Last Call for draft-ietf-httpbis-semantics-19
2021-09-13
19 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-09-13
19 Amy Vezza IESG has approved the document
2021-09-13
19 Amy Vezza Closed "Approve" ballot
2021-09-13
19 Amy Vezza Ballot approval text was generated
2021-09-13
19 Francesca Palombini The IESG approved the intended status change from Proposed to Internet Standard following the September 9, 2021 IESG Teleconference and follow-up email thread.
2021-09-13
19 (System) Removed all action holders (IESG state changed)
2021-09-13
19 Francesca Palombini IESG state changed to Approved-announcement to be sent from Waiting for AD Go-Ahead
2021-09-12
19 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-09-12
19 Julian Reschke New version available: draft-ietf-httpbis-semantics-19.txt
2021-09-12
19 (System) New version approved
2021-09-12
19 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-09-12
19 Julian Reschke Uploaded new revision
2021-09-06
18 Bron Gondwana Request for Last Call review by ARTART Completed: Ready. Reviewer: Bron Gondwana. Sent review to list.
2021-09-06
18 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-09-03
18 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-09-03
18 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-semantics-18. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-semantics-18. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that 13 registry actions will need to be completed upon approval of this document.

First, in the Uniform Resource Identifier (URI) Schemes registry at

https://www.iana.org/assignments/uri-schemes/

the following URI schemes will have their references changed:

URI Scheme: http
Template:
Description: Hypertext Transfer Protocol
Status: Permanent
Well-known URI Support: [RFC8615]
Reference: [ RFC-to-be; Section 4.2.1 ]
Notes:

URI Scheme: https
Template:
Description: Hypertext Transfer Protocol Secure
Status: Permanent
Well-known URI Support: [RFC8615]
Reference: [ RFC-to-be; Section 4.2.2 ]
Notes:

Second, in the Hypertext Transfer Protocol (HTTP) Method registry at

https://www.iana.org/assignments/http-methods/

the reference for the registry will be changed to Section 16.1.1 of this document and the following methods will be updated or (as in the case of "*") added:

Method: CONNECT
Safe: no
Idempotent: no
Reference: [ RFC-to-be; Section 9.3.6 ]

Method: DELETE
Safe: no
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.5 ]

Method: GET
Safe: yes
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.1 ]

Method: HEAD
Safe: yes
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.2 ]

Method: OPTIONS
Safe: yes
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.7 ]

Method: POST
Safe: no
Idempotent: no
Reference: [ RFC-to-be; Section 9.3.3 ]

Method: PUT
Safe: no
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.4 ]

Method: TRACE
Safe: yes
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.8 ]

Method: *
Safe: no
Idempotent: no
Reference: [ RFC-to-be; Section 18.2 ]

Third, in the Hypertext Transfer Protocol (HTTP) Status Code registry at

https://www.iana.org/assignments/http-status-codes/

the reference for the registry will be changed to Section 16.2.1 of this document and the following status codes will be updated or (as in the case of "(Unused)") added:

+=======+===============================+===============================+
| Value | Description | Reference |
+=======+===============================+===============================+
| 100 | Continue | [ RFC-to-be; Section 15.2.1 ] |
+-------+-------------------------------+-------------------------------+
| 101 | Switching Protocols | [ RFC-to-be; Section 15.2.2 ] |
+-------+-------------------------------+-------------------------------+
| 200 | OK | [ RFC-to-be; Section 15.3.1 ] |
+-------+-------------------------------+-------------------------------+
| 201 | Created | [ RFC-to-be; Section 15.3.2 ] |
+-------+-------------------------------+-------------------------------+
| 202 | Accepted | [ RFC-to-be; Section 15.3.3 ] |
+-------+-------------------------------+-------------------------------+
| 203 | Non-Authoritative Information | [ RFC-to-be; Section 15.3.4 ] |
+-------+-------------------------------+-------------------------------+
| 204 | No Content | [ RFC-to-be; Section 15.3.5 ] |
+-------+-------------------------------+-------------------------------+
| 205 | Reset Content | [ RFC-to-be; Section 15.3.6 ] |
+-------+-------------------------------+-------------------------------+
| 206 | Partial Content | [ RFC-to-be; Section 15.3.7 ] |
+-------+-------------------------------+-------------------------------+
| 300 | Multiple Choices | [ RFC-to-be; Section 15.4.1 ] |
+-------+-------------------------------+-------------------------------+
| 301 | Moved Permanently | [ RFC-to-be; Section 15.4.2 ] |
+-------+-------------------------------+-------------------------------+
| 302 | Found | [ RFC-to-be; Section 15.4.3 ] |
+-------+-------------------------------+-------------------------------+
| 303 | See Other | [ RFC-to-be; Section 15.4.4 ] |
+-------+-------------------------------+-------------------------------+
| 304 | Not Modified | [ RFC-to-be; Section 15.4.5 ] |
+-------+-------------------------------+-------------------------------+
| 305 | Use Proxy | [ RFC-to-be; Section 15.4.6 ] |
+-------+-------------------------------+-------------------------------+
| 306 | (Unused) | [ RFC-to-be; Section 15.4.7 ] |
+-------+-------------------------------+-------------------------------+
| 307 | Temporary Redirect | [ RFC-to-be; Section 15.4.8 ] |
+-------+-------------------------------+-------------------------------+
| 308 | Permanent Redirect | [ RFC-to-be; Section 15.4.9 ] |
+-------+-------------------------------+-------------------------------+
| 400 | Bad Request | [ RFC-to-be; Section 15.5.1 ] |
+-------+-------------------------------+-------------------------------+
| 401 | Unauthorized | [ RFC-to-be; Section 15.5.2 ] |
+-------+-------------------------------+-------------------------------+
| 402 | Payment Required | [ RFC-to-be; Section 15.5.3 ] |
+-------+-------------------------------+-------------------------------+
| 403 | Forbidden | [ RFC-to-be; Section 15.5.4 ] |
+-------+-------------------------------+-------------------------------+
| 404 | Not Found | [ RFC-to-be; Section 15.5.5 ] |
+-------+-------------------------------+-------------------------------+
| 405 | Method Not Allowed | [ RFC-to-be; Section 15.5.6 ] |
+-------+-------------------------------+-------------------------------+
| 406 | Not Acceptable | [ RFC-to-be; Section 15.5.7 ] |
+-------+-------------------------------+-------------------------------+
| 407 | Proxy Authentication Required | [ RFC-to-be; Section 15.5.8 ] |
+-------+-------------------------------+-------------------------------+
| 408 | Request Timeout | [ RFC-to-be; Section 15.5.9 ] |
+-------+-------------------------------+-------------------------------+
| 409 | Conflict | [ RFC-to-be; Section 15.5.10] |
+-------+-------------------------------+-------------------------------+
| 410 | Gone | [ RFC-to-be; Section 15.5.11] |
+-------+-------------------------------+-------------------------------+
| 411 | Length Required | [ RFC-to-be; Section 15.5.12] |
+-------+-------------------------------+-------------------------------+
| 412 | Precondition Failed | [ RFC-to-be; Section 15.5.13] |
+-------+-------------------------------+-------------------------------+
| 413 | Content Too Large | [ RFC-to-be; Section 15.5.14] |
+-------+-------------------------------+-------------------------------+
| 414 | URI Too Long | [ RFC-to-be; Section 15.5.15] |
+-------+-------------------------------+-------------------------------+
| 415 | Unsupported Media Type | [ RFC-to-be; Section 15.5.16] |
+-------+-------------------------------+-------------------------------+
| 416 | Range Not Satisfiable | [ RFC-to-be; Section 15.5.17] |
+-------+-------------------------------+-------------------------------+
| 417 | Expectation Failed | [ RFC-to-be; Section 15.5.18] |
+-------+-------------------------------+-------------------------------+
| 418 | (Unused) | [ RFC-to-be; Section 15.5.19] |
+-------+-------------------------------+-------------------------------+
| 421 | Misdirected Request | [ RFC-to-be; Section 15.5.20] |
+-------+-------------------------------+-------------------------------+
| 422 | Unprocessable Content | [ RFC-to-be; Section 15.5.21] |
+-------+-------------------------------+-------------------------------+
| 426 | Upgrade Required | [ RFC-to-be; Section 15.5.22] |
+-------+-------------------------------+-------------------------------+
| 500 | Internal Server Error | [ RFC-to-be; Section 15.6.1 ] |
+-------+-------------------------------+-------------------------------+
| 501 | Not Implemented | [ RFC-to-be; Section 15.6.2 ] |
+-------+-------------------------------+------------------------------+
| 502 | Bad Gateway | [ RFC-to-be; Section 15.6.3 ] |
+-------+-------------------------------+-------------------------------+
| 503 | Service Unavailable | [ RFC-to-be; Section 15.6.4 ] |
+-------+-------------------------------+-------------------------------+
| 504 | Gateway Timeout | [ RFC-to-be; Section 15.6.5 ] |
+-------+-------------------------------+-------------------------------+
| 505 | HTTP Version Not Supported | [ RFC-to-be; Section 15.6.6 ] |
+-------+-------------------------------+-------------------------------+

The registration procedure for this registry remains IETF Review as defined by RFC8126.

Fourth, a new registry called the Hypertext Transfer Protocol (HTTP) Field Name registry will be created. The new registry is to be located at

https://www.iana.org/assignments/http-fields/

All entries in the Permanent and Provisional Message Header Registries located at

https://www.iana.org/assignments/message-headers/

with the protocol 'http' are to be moved to it, with the following changes applied:

1. The 'Applicable Protocol' field is to be omitted.

2. Entries with a status of 'standard', 'experimental', 'reserved', or 'informational' are to have a status of 'permanent'.

3. Provisional entries without a status are to have a status of 'provisional'.

4. Permanent entries without a status (after confirmation that the registration document did not define one) will have a status of 'provisional'. The Expert(s) can choose to update their status if there is evidence that another is more appropriate.

The registration procedure for new registrations with permanent status is Specification Required, as defined in RFC8126. The registration procedure for new registrations with provisional status is Expert Review.

Fifth, in the Permanent and Provisional Message Header Registries at

https://www.iana.org/assignments/message-headers/

a note (with a link to the new registry) will be added to indicate that the HTTP field name registrations have moved.

Sixth, in the newly-created Hypertext Transfer Protocol (HTTP) Field Name registry at

https://www.iana.org/assignments/http-fields/

the following entries should be updated or added (and in each case the section number will be preceded by [ "RFC-to-be, Section" ]:

+===========================+============+========+============+
| Field Name | Status | Ref. | Comments |
+===========================+============+========+============+
| Accept | standard | 12.5.1 | |
+---------------------------+------------+--------+------------+
| Accept-Charset | deprecated | 12.5.2 | |
+---------------------------+------------+--------+------------+
| Accept-Encoding | standard | 12.5.3 | |
+---------------------------+------------+--------+------------+
| Accept-Language | standard | 12.5.4 | |
+---------------------------+------------+--------+------------+
| Accept-Ranges | standard | 14.3 | | |
+---------------------------+------------+--------+------------+
| Allow | standard | 10.2.1 | |
+---------------------------+------------+--------+------------+
| Authentication-Info | standard | 11.6.3 | |
+---------------------------+------------+--------+------------+
| Authorization | standard | 11.6.2 | |
+---------------------------+------------+--------+------------+
| Connection | standard | 7.6.1 | |
+---------------------------+------------+--------+------------+
| Content-Encoding | standard | 8.4 | |
+---------------------------+------------+--------+------------+
| Content-Language | standard | 8.5 | |
+---------------------------+------------+--------+------------+
| Content-Length | standard | 8.6 | |
+---------------------------+------------+--------+------------+
| Content-Location | standard | 8.7 | |
+---------------------------+------------+--------+------------+
| Content-Range | standard | 14.4 | |
+---------------------------+------------+--------+------------+
| Content-Type | standard | 8.3 | |
+---------------------------+------------+--------+------------+
| Date | standard | 6.6.1 | |
+---------------------------+------------+--------+------------+
| ETag | standard | 8.8.3 | |
+---------------------------+------------+--------+------------+
| Expect | standard | 10.1.1 | |
+---------------------------+------------+--------+------------+
| From | standard | 10.1.2 | |
+---------------------------+------------+--------+------------+
| Host | standard | 7.2 | |
+---------------------------+------------+--------+------------+
| If-Match | standard | 13.1.1 | |
+---------------------------+------------+--------+------------+
| If-Modified-Since | standard | 13.1.3 | |
+---------------------------+------------+--------+------------+
| If-None-Match | standard | 13.1.2 | |
+---------------------------+------------+--------+------------+
| If-Range | standard | 13.1.5 | |
+---------------------------+------------+--------+------------+
| If-Unmodified-Since | standard | 13.1.4 | |
+---------------------------+------------+--------+------------+
| Last-Modified | standard | 8.8.2 | |
+---------------------------+------------+--------+------------+
| Location | standard | 10.2.2 | |
+---------------------------+------------+--------+------------+
| Max-Forwards | standard | 7.6.2 | |
+---------------------------+------------+--------+------------+
| Proxy-Authenticate | standard | 11.7.1 | |
+---------------------------+------------+--------+------------+
| Proxy-Authentication-Info | standard | 11.7.3 | |
+---------------------------+------------+--------+------------+
| Proxy-Authorization | standard | 11.7.2 | |
+---------------------------+------------+--------+------------+
| Range | standard | 14.2 | |
+---------------------------+------------+--------+------------+
| Referer | standard | 10.1.3 | |
+---------------------------+------------+--------+------------+
| Retry-After | standard | 10.2.3 | |
+---------------------------+------------+--------+------------+
| Server | standard | 10.2.4 | |
+---------------------------+------------+--------+------------+
| TE | standard | 10.1.4 | |
+---------------------------+------------+--------+------------+
| Trailer | standard | 6.6.2 | |
+---------------------------+------------+--------+------------+
| Upgrade | standard | 7.8 | |
+---------------------------+------------+--------+------------+
| User-Agent | standard | 10.1.5 | |
+---------------------------+------------+--------+------------+
| Vary | standard | 12.5.5 | |
+---------------------------+------------+--------+------------+
| Via | standard | 7.6.3 | |
+---------------------------+------------+--------+------------+
| WWW-Authenticate | standard | 11.6.1 | |
+---------------------------+------------+--------+------------+
| * | standard | 12.5.5 | (reserved) |
+---------------------------+------------+--------+------------+

Seventh, in the newly-created Hypertext Transfer Protocol (HTTP) Field Name registry at

https://www.iana.org/assignments/http-fields/

the entry for the "Content-MD5" item in the new registry will have its status listed as "obsoleted," with references to RFC2616, Section 14.15, and RFC7231, Appendix B.

Eighth, IANA understands that in the Hypertext Transfer Protocol (HTTP) Authentication Scheme registry located at

https://www.iana.org/assignments/http-authschemes

the current reference for the registry itself will be replaced with a reference to Section 16.6.1 of this document.

Ninth, in the HTTP Content Coding registry at

https://www.iana.org/assignments/http-parameters/

the following entries should be updated:

+============+===========================================+=========+
| Name | Description | Ref. |
+============+===========================================+=========+
| compress | UNIX "compress" data format [Welch] | 8.4.1.1 |
+------------+-------------------------------------------+---------+
| deflate | "deflate" compressed data ([RFC1951]) | 8.4.1.2 |
| | inside the "zlib" data format ([RFC1950]) | |
+------------+-------------------------------------------+---------+
| gzip | GZIP file format [RFC1952] | 8.4.1.3 |
+------------+-------------------------------------------+---------+
| identity | Reserved | 12.5.3 |
+------------+-------------------------------------------+---------+
| x-compress | Deprecated (alias for compress) | 8.4.1.1 |
+------------+-------------------------------------------+---------+
| x-gzip | Deprecated (alias for gzip) | 8.4.1.3 |
+------------+-------------------------------------------+---------+

Tenth, in the HTTP Range Unit registry at

https://www.iana.org/assignments/http-parameters/

the following entries should be updated:

+=================+==================================+========+
| Range Unit Name | Description | Ref. |
+=================+==================================+========+
| bytes | a range of octets | 14.1.2 |
+-----------------+----------------------------------+--------+
| none | reserved as keyword to indicate | 14.3 |
| | range requests are not supported | |
+-----------------+----------------------------------+--------+

The registration procedure for the registry remains IETF Review as defined in RFC 8126.

Eleventh, in the media types registry at

https://www.iana.org/assignments/media-types

the existing registration for multipart/byteranges will have its current reference replaced with a reference to this document and its template information replaced with the information from Section 14.6..

Twelfth, in the Service Name and Transport Protocol Port Number registry at

https://www.iana.org/assignments/service-names-port-numbers/

the existing registrations for the ports 80 and 443 that use UDP or TCP will be modified as follows:

1. use this document as their sole reference
2. when currently unspecified, set "Assignee" to "IESG" and
"Contact" to "IETF Chair."

Thirteenth, in the Hypertext Transfer Protocol (HTTP) Upgrade Token registry at

https://www.iana.org/assignments/http-upgrade-tokens

the current reference for HTTP will be replaced with a reference to [RFC-to-be, Section 2.5].

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-08-24
18 Barry Leiba Request for Last Call review by ARTART is assigned to Bron Gondwana
2021-08-24
18 Barry Leiba Request for Last Call review by ARTART is assigned to Bron Gondwana
2021-08-23
18 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-09-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-semantics@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com …
The following Last Call announcement was sent out (ends 2021-09-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-semantics@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: SECOND Last Call:  (HTTP Semantics) to Internet Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'HTTP Semantics'
  as Internet Standard

This second Last Call is specifically on the intended RFC status change, which
was incorrectly set to Proposed Standard on the previous Last Call.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on the intended RFC status change from Proposed Standard to
Internet Standard. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-09-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Hypertext Transfer Protocol (HTTP) is a stateless application-
  level protocol for distributed, collaborative, hypertext information
  systems.  This document describes the overall architecture of HTTP,
  establishes common terminology, and defines aspects of the protocol
  that are shared by all versions.  In this definition are core
  protocol elements, extensibility mechanisms, and the "http" and
  "https" Uniform Resource Identifier (URI) schemes.

  This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
  7232
, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions
  of RFC 7230.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-semantics/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7405: Case-Sensitive String Support in ABNF (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc8446: The Transport Layer Security (TLS) Protocol Version 1.3 (Proposed Standard - Internet Engineering Task Force (IETF))



2021-08-23
18 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-08-23
18 Francesca Palombini Last call was requested
2021-08-23
18 Francesca Palombini IESG state changed to Last Call Requested from IESG Evaluation::AD Followup
2021-08-23
18 Francesca Palombini Last call announcement was changed
2021-08-23
18 Francesca Palombini Last call announcement was generated
2021-08-23
18 Francesca Palombini Fixing intended RFC status (see https://mailarchive.ietf.org/arch/msg/httpbisa/V0om3C8M-9vsS0761CktqBHK7VU/)
2021-08-23
18 Francesca Palombini Intended Status changed to Internet Standard from Proposed Standard
2021-08-18
18 Julian Reschke New version available: draft-ietf-httpbis-semantics-18.txt
2021-08-18
18 (System) New version approved
2021-08-18
18 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-08-18
18 Julian Reschke Uploaded new revision
2021-07-25
17 Benjamin Kaduk
[Ballot comment]
Thank you for addressing my Discuss points (both on this document
and on -messaging, since the proper fix for that concern ended up …
[Ballot comment]
Thank you for addressing my Discuss points (both on this document
and on -messaging, since the proper fix for that concern ended up
being in this document)!  I will duly ballot Yes, as promised.

However, I will retain unchanged the COMMENT section from my ballot
position on the -16, since on further inspection there are many of
them that do not seem to have been discussed in github yet.

I also had one new comment on the -17: in Section 10.2 we had some
good text cleanup (I think, prompted by one of my comments -- thank you!),
but the removed text included a note about how the semantics of a response
header field might be refined by the semantics of the request method and/or
the response status code.  That seems like it would be useful to have
mentioned, and I'm not sure if this text was replicated elsewhere.

=====BEGIN PREVIOUS COMMENT SECTION=====
This document updates RFC 3864, which is part of BCP 90.
However, this document is targeting Proposed Standard status, which
means it cannot become a part of BCP 90 as part of that update.
Did we consider splitting out the RFC 3864 updates into a separate,
BCP-level, document, that would become part of BCP 90?

Section 1.2

  HTTP/2 ([RFC7540]) introduced a multiplexed session layer on top of
  the existing TLS and TCP protocols for exchanging concurrent HTTP
  messages with efficient field compression and server push.  HTTP/3
  ([HTTP3]) provides greater independence for concurrent messages by
  using QUIC as a secure multiplexed transport over UDP instead of TCP.

My understanding was that h2 and h3 also use non-text-based headers, in
contrast to HTTP/1.1's "text-based messaging syntax" that we mention
earlier.  Is that non-text nature worth noting here?

Section 3.7

                                Proxies are often used to group an
  organization's HTTP requests through a common intermediary for the
  sake of security, annotation services, or shared caching.  [...]

The term "security" can mean so many different things to different
audiences that its meaning in isolation is pretty minimal.  I suggest
finding a more specific term for the intended usage, perhaps relating to
an auditing, exfiltration protection, and/or content-filtering function.

  For example, an _interception proxy_ [RFC3040] (also commonly known
  as a _transparent proxy_ [RFC1919]) differs from an HTTP proxy
  because it is not chosen by the client.  Instead, an interception
  proxy filters or redirects outgoing TCP port 80 packets (and
  occasionally other common port traffic).  Interception proxies are
  commonly found on public network access points, as a means of
  enforcing account subscription prior to allowing use of non-local
  Internet services, and within corporate firewalls to enforce network
  usage policies.

Is this text still accurate in the era of https-everywhere and Let's
Encrypt?

Section 3.9

As Éric notes, OpenSSL 0.9.7l supports only SSL and TLSv1.0, which per
RFC 8996 is no longer permitted -- I concur with his recommendation to
update the example (potentially including Last-Modified).

Section 4.2.x

  The hierarchical path component and optional query component identify
  the target resource within that origin server's name space.

Would a BCP 190 reference be appropriate here (emphasizing that the name
space belongs to the origin server)?

Section 4.2.2

  The "https" URI scheme is hereby defined for minting identifiers
  within the hierarchical namespace governed by a potential origin
  server listening for TCP connections on a given port and capable of
  establishing a TLS ([RFC8446]) connection that has been secured for
  HTTP communication.  [...]

Is "capable" the correct prerequisite, or does the server need to
actually do so on that port?  (Given the following definition of
"secured", though, the ability to successfully do so would seem to
depend on the trust anchor configuration on the client, which is not
really something the server can control...)

Section 4.3.3

  Note, however, that the above is not the only means for obtaining an
  authoritative response, nor does it imply that an authoritative
  response is always necessary (see [Caching]).

Is it intentional that this paragraph diverges from the analogous
content in §4.3.2 (which also mentions Alt-Svc and other protocols
"outside the scope of this document")?

Section 5.3

      |  *Note:* In practice, the "Set-Cookie" header field ([RFC6265])
      |  often appears in a response message across multiple field lines
      |  and does not use the list syntax, violating the above
      |  requirements on multiple field lines with the same field name.
      |  Since it cannot be combined into a single field value,
      |  recipients ought to handle "Set-Cookie" as a special case while
      |  processing fields.  (See Appendix A.2.3 of [Kri2001] for
      |  details.)

The reference seems to conclude only that the situation for "Set-Cookie"
is underspecified, and doesn't really give me much guidance on what to
do if I receive a message with multiple field lines for "Set-Cookie".
(It does talk about the "Cookie" field and how semicolon is used to
separate cookie values, which implies that "Cookie" would get special
treatment to use semicolon to join field lines, but doesn't really give
me the impression that "Set-Cookie" should also have such treatment.)

Section 5.4

  A client MAY discard or truncate received field lines that are larger
  than the client wishes to process if the field semantics are such
  that the dropped value(s) can be safely ignored without changing the
  message framing or response semantics.

Is it worth saying anything about fields that the client does not
recognize?  (Per the previous discussion, the server needs to either
know that the client recognizes the field or only send fields that are
safe to ignore if unrecognized, if I understand correctly...)

Section 6.4.1

  In a response, the content's purpose is defined by both the request
  method and the response status code (Section 15).  For example, the
  content of a 200 (OK) response to GET (Section 9.3.1) represents the
  current state of the target resource, as observed at the time of the
  message origination date (Section 10.2.2), whereas the content of the
  same status code in a response to POST might represent either the
  processing result or the new state of the target resource after
  applying the processing.

Doesn't the last clause mean that there is some additional (meta)data
that can affect the content's purpose (e.g., a Content-Location field)?
Or how else would one know if the 200 POST response is the processing
result vs the new state?  It seems incomplete to just say "is defined by
both" and list only method and status code as the defining factors.

Section 7.6.3

[I had the same question as Martin Duke about default *TCP* port, and
the interaction with the scheme.  I see that it has been answered since
I initially drafted these notes, hooray.]

Section 7.7

  A proxy MUST NOT modify the "absolute-path" and "query" parts of the
  received target URI when forwarding it to the next inbound server,
  except as noted above to replace an empty path with "/" or "*".

I found where (in the discussion of normalization in §4.2.3) we say to
replace the empty path with "/" for non-OPTIONS requests.  I couldn't
find anywhere "above" where it was noted to replace an empty path with
"*" (presumably, for the OPTIONS requests), though.

Section 8.3

                          Implementers are encouraged to provide a means
  to disable such sniffing.

"encouraged to provide a means to disable" could be read as also
encouraging implementation of the (sniffing) mechanism itself.  Is it
actually the case that we encourage implementation of MIME sniffing?

Section 8.8.1

                                                                  A
  strong validator is unique across all versions of all representations
  associated with a particular resource over time.  [...]

My understanding is that, e.g., a cryptographic hash over the
representation and metadata would be intended to be a strong validator,
but for such a construction the "unique" property can only be guaranteed
probabilistically.  Are we comfortable with this phrasing that implies
an absolute requirement?

Section 8.8.4

  *  SHOULD send the Last-Modified value in non-subrange cache
      validation requests (using If-Modified-Since) if only a Last-
      Modified value has been provided by the origin server.

  *  MAY send the Last-Modified value in subrange cache validation
      requests (using If-Unmodified-Since) if only a Last-Modified value
      has been provided by an HTTP/1.0 origin server.  The user agent
      SHOULD provide a way to disable this, in case of difficulty.

I'm failing to come up with an explanation for why it's important to
specifically call out the HTTP/1.0 origin server in the latter case.
What's special about an HTTP/1.1 origin server that only provided a
Last-Modified value and subrange cache validation requests that makes
the MAY inapplicable?  (What's the actual expected behavior for that
situation?)

Section 9.2.2

  A request method is considered _idempotent_ if the intended effect on
  the server of multiple identical requests with that method is the
  same as the effect for a single such request.  [...]

I sometimes worry that a definition of idempotent like this hides the
interaction of repeated idempotent requests with other requests
modifying the same resource.  A+A is equivalent to A, but A+B+A is often
not equivalent to A+B...

Section 9.3.5

  Likewise, other implementation aspects of a resource might need to be
  deactivated or archived as a result of a DELETE, such as database or
  gateway connections.  In general, it is assumed that the origin
  server will only allow DELETE on resources for which it has a
  prescribed mechanism for accomplishing the deletion.

The specific phrasing of "only allow DELETE [...]" calls to mind (for
me) an expectation of authorization checks as well.  In some sense this
is no different than for POST or PUT, and thus may not be worth
particular mention here, but I thought I'd ask whether it makes sense to
mention authorization (and authentication).

  A client SHOULD NOT generate content in a DELETE request.  Content
  received in a DELETE request has no defined semantics, cannot alter
  the meaning or target of the request, and might lead some
  implementations to reject the request.

We had a similar paragraph earlier in the discussion of GET and HEAD,
but those paragraphs included a clause about "close the connection
because of its potential as a request smuggling attack" -- is DELETE not
at risk of use for request smuggling?

Section 10.1.1

  *  A server that responds with a final status code before reading the
      entire request content SHOULD indicate whether it intends to close
      the connection (e.g., see Section 9.6 of [Messaging]) or continue
      reading the request content.

The referenced section seems to cover the "close" connection option,
which is a positive signal of intent to close.  Is the absence of that
connection option to be interpreted as a positive signal of intent to
continue reading the request content, or is there some other positive
signal of such intent to continue reading?

Section 10.1.2

  A server SHOULD NOT use the From header field for access control or
  authentication.

It seems that the level of security provided by the From header field is
at most that of a bearer token, and that the natural choice of such
token is easily guessable (though unguessable choices are possible).
I'm having a hard time coming up with an IETF-consensus scenario where
it would make sense to use From for access control or authentication
(i.e., could this be MUST NOT instead?).

Section 10.1.3

                Some servers use the Referer header field as a means of
  denying links from other sites (so-called "deep linking") or
  restricting cross-site request forgery (CSRF), but not all requests
  contain it.

I think we should say something about the effectiveness of Referer
checks as a CSRF mitigation mechanism.

                        Most general-purpose user agents do not send the
  Referer header field when the referring resource is a local "file" or
  "data" URI.  A user agent SHOULD NOT send a Referer header field if

This seems like a curious statement.  Are we expecting future
general-purpose user agents to emulate this behavior?  If so, then why
not recommend it explicitly?

  the referring resource was accessed with a secure protocol and the
  request target has an origin differing from that of the referring
  resource, unless the referring resource explicitly allows Referer to
  be sent.  A user agent MUST NOT send a Referer header field in an

How does a referring resource indicate that Referer should be sent?

Section 10.1.4

  The TE field value consists of a list of tokens, each allowing for
  optional parameters (except for the special case "trailers").

Should the prose mention the 'weight' part of the t-codings construction
(the "weight" production itself does not seem to be defined until §11.4.2)?

Section 10.1.5

  For example, a sender might indicate that a message integrity check
  will be computed as the content is being streamed and provide the
  final signature as a trailer field.  This allows a recipient to

Please pick one of "message integrity check" and "signature" and use it
consistently; these are both cryptographic terms of art (with different
meanings).

  Because the Trailer field is not removed by intermediaries, it can
  also be used by downstream recipients to discover when a trailer
  field has been removed from a message.

It seems that this usage is only possible if sending the Trailer field is a
binding commitment to emit the relevant trailer fields; otherwise the
recipient cannot distinguish between a removal by an intermediary and a sender
declining to generate the trailer field.

Section 10.1.6

        A user agent SHOULD send a User-Agent header field in each
  request unless specifically configured not to do so.

(I assume that a reference to client-hints (or UA-CH) was considered and
rejected.)

  A user agent SHOULD NOT generate a User-Agent header field containing
  needlessly fine-grained detail and SHOULD limit the addition of
  subproducts by third parties.  Overly long and detailed User-Agent
  field values increase request latency and the risk of a user being
  identified against their wishes ("fingerprinting").

client-hints might even be more appropriate as a reference here than it
would be above...or just in §17.13.

Section 10.2

It seems like it might be worth listing the fields already defined in the
previous section (as request context fields) that can also appear as response
context fields.

Section 12.2

  Reactive negotiation suffers from the disadvantages of transmitting a
  list of alternatives to the user agent, which degrades user-perceived
  latency if transmitted in the header section, and needing a second
  request to obtain an alternate representation.  Furthermore, this
  specification does not define a mechanism for supporting automatic
  selection, though it does not prevent such a mechanism from being
  developed as an extension.

I'm not sure that I understand how an HTTP extension would help specify
a mechanism for automatic selection in reactive negotiation; isn't this
just an implementation detail in the user-agent?

Section 12.5.1

      |  *Note:* Use of the "q" parameter name to control content
      |  negotiation is due to historical practice.  Although this
      |  prevents any media type parameter named "q" from being used
      |  with a media range, such an event is believed to be unlikely
      |  given the lack of any "q" parameters in the IANA media type
      |  registry and the rare usage of any media type parameters in
      |  Accept.  Future media types are discouraged from registering
      |  any parameter named "q".

This note seems like it would be more useful in the IANA media-types
registry than "some random protocol specification that uses media
types".

Section 12.5.3

  For example,

  Accept-Encoding: compress, gzip
  Accept-Encoding:
  Accept-Encoding: *
  Accept-Encoding: compress;q=0.5, gzip;q=1.0
  Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Are these supposed to be multiple standalone examples or one single example with
multiple field lines?  (I note that they appear in a single
element in the XML source.)  If they are supposed to be one single
example, I would have expected some remark about the combination of "*"
and "*;q=0" (my understanding is that the q=0 renders codings not listed
as unacceptable, even despite the implicitly q=1 wildcard).
It seems that in other instances where we provide multiple examples in
a single artwork, the prefacing text is "Examples:" plural, that makes
some effort to disambiguate.

      |  *Note:* Most HTTP/1.0 applications do not recognize or obey
      |  qvalues associated with content-codings.  This means that
      |  qvalues might not work and are not permitted with x-gzip or
      |  x-compress.

This wording implies to me that there is a normative requirement
somewhere else that qvalues cannot be used with x-gzip and x-compress,
but I'm not sure where that would be.  (It's also a bit hard to
understand how x-gzip would be affected but not plain gzip, given that
§18.6 lists it as an alias for gzip ... additional restrictions don't
quite match up with an "alias" nature.)

Section 12.5.4

  It might be contrary to the privacy expectations of the user to send
  an Accept-Language header field with the complete linguistic
  preferences of the user in every request (Section 17.13).

This leaves me wondering how to improve on the situation and pick which
subset of requests to send the header field in.  I would expect that a
blind random sampling approach would not yield privacy improvements over
always sending them.

Section 12.5.5

  An origin server SHOULD send a Vary header field when its algorithm
  for selecting a representation varies based on aspects of the request
  message other than the method and target URI, unless the variance
  cannot be crossed or the origin server has been deliberately
  configured to prevent cache transparency.  [...]

I don't think I know what it means to "cross" a variance.  The example
(elided from this comment) about Authorization not needing to be
included gives some hint as to what is meant, but I still don't have a
clear picture.

Section 13.2.2

  5.  When the method is GET and both Range and If-Range are present,
      evaluate the If-Range precondition:

      *  if the validator matches and the Range specification is
          applicable to the selected representation, respond 206
          (Partial Content)

  6.  Otherwise,

      *  all conditions are met, so perform the requested action and
          respond according to its success or failure.

I think that if the If-Range doesn't match, we're supposed to ignore the
Range header field when performing the requested action, which doesn't
seem to match up with this unadorned directive to "perform the requested
action" (which would include the Range header field).
(We might also change point (5) to use the "if true" phrasing that the
other items use in the context of evaluating the precondition.)

Section 15.4.9

      |  *Note:* This status code is much younger (June 2014) than its
      |  sibling codes, and thus might not be recognized everywhere.
      |  See Section 4 of [RFC7538] for deployment considerations.

This document obsoletes RFC 7538; if we believe that content is still
useful we should probably consider incorporating it into this document.

Section 16.3.1

  Field names are registered on the advice of a Designated Expert
  (appointed by the IESG or their delegate).  Fields with the status
  'permanent' are Specification Required ([RFC8126], Section 4.6).

I would have expected IANA to ask for the phrase "Expert Review" to be
used for the general case (if they did not already), since that's the
relevant registration policy defined in RFC 8126.

  Registration requests consist of at least the following information:
[...]
  Specification document(s):
      Reference to the document that specifies the field, preferably

If the registration consists of "at least" a group of information that
includes a specification document, doesn't that mean the policy is
*always* "Specification Required", not just for permanent registrations?

  Provisional entries can be removed by the Expert(s) if - in
  consultation with the community - the Expert(s) find that they are
  not in use.  The Experts can change a provisional entry's status to
  permanent at any time.

(The ability to freely convert a provisional registration to permanent
seems to also require a specification document to always be present,
even for provisional registrations.)

Section 17

A few potential considerations that don't seem to be mentioned in the
subsections:

- Implementation divergence in handling multi-member field values when
  singletons are expected, could lead to security issues (in a similar
  vein as how request smuggling works)

- Though ETag is formally opaque to clients, any internal structure to
  the values could still be inspected and attacked by a malicious
  client.  We might consider giving guidance that ETag values should
  be unpredictable.

- When the same information is present at multiple protocol layers
  (e.g., the transport port number and the Host field value), in the
  general case, attacks are possible if there is not check for
  consistency of the values in the different layers.  It's often helpful
  to provide guidance on which entit(ies) should perform the check, to
  avoid scenarios where all parties are expecting "someone else" to do
  it.

- Relatedly, the port value is part of the https "origin" concept, but is not
  authenticated by the certificate and could be modified (in the
  transport layer) by an on-path attacker.  The safety of per-origin
  isolation relies on the server to check that the port intended by the
  client matches the port the request was actually received on.

- We mention that in response to some 3xx redirection responses, a
  client capable of link editing might do so automatically.  Doing so
  for http-not-s responses would allow for a form of privilege
  escalation, converting even a temporary access into more permanent
  changes on referring resources.

- We make heavy use of URIs and URI components; referencing the security
  considerations of RFC 3986 might be worthwhile

Section 17.1

  Unfortunately, communicating authority to users can be difficult.
  For example, _phishing_ is an attack on the user's perception of
  authority, where that perception can be misled by presenting similar
  branding in hypertext, possibly aided by userinfo obfuscating the
  authority component (see Section 4.2.1).  [...]

We might also mention "confusable" domain names here as well (which are
possible even without resorting to IDNs).

Section 17.5

Should we also discuss situations where there might be redundant lengths
at different encoding layers (e.g., HTTP framing and MIME multipart
boundaries), in a similar vein to
https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34#section-10.8
?

Section 17.16.3

  Authentication schemes that solely rely on the "realm" mechanism for
  establishing a protection space will expose credentials to all
  resources on an origin server.  [...]

There's also not any clear authorization mechanism for the origin to claim
use of a given realm value, which can lead to the client sending
credentials for the claimed realm without knowing that the server should
be receiving such credentials.

Section 19.2

Should RFC 5322 be normative?  We rely on it for, e.g., the "mailbox"
ABNF construction.

Appendix A

[Just noting that I did not attempt to validate the ABNF, since the
shepherd writeup notes that they have been validated]

Appendix B.4

  Clarified that If-Unmodified-Since doesn't apply to a resource
  without a concept of modification time.  (Section 13.1.4)

I couldn't really locate which text was supposed to be providing this
clarification.


NITS

Section 3.1

                                              Most resources are
  identified by a Uniform Resource Identifier (URI), as described in
  Section 4.
[...]
  HTTP relies upon the Uniform Resource Identifier (URI) standard
  [RFC3986] to indicate the target resource (Section 7.1) and
  relationships between resources.

Are these two statements compatible?  (What is used for the non-URI
resource identification scenarios?)

Section 5.5

We seem to use the obs-text ABNF construction prior to its definition,
which is in Section 5.6.4.

Section 5.6.1.1

  In any production that uses the list construct, a sender MUST NOT
  generate empty list elements.  In other words, a sender MUST generate
  lists that satisfy the following syntax:

    1#element => element *( OWS "," OWS element )

Are the two formulations equivalent without some restriction on
'element' itself?

Section 6.4.2

  2.  If the request method is GET and the response status code is 200
      (OK), the content is a representation of the resource identified
      by the target URI (Section 7.1).

  3.  If the request method is GET and the response status code is 203
      (Non-Authoritative Information), the content is a potentially
      modified or enhanced representation of the target resource as
      provided by an intermediary.

  4.  If the request method is GET and the response status code is 206
      (Partial Content), the content is one or more parts of a
      representation of the resource identified by the target URI
      (Section 7.1).

  5.  If the response has a Content-Location header field and its field
      value is a reference to the same URI as the target URI, the
      content is a representation of the target resource.

I count two "target resource" and two "resource identified by the target
URI".  Is there an important distinction between those two phrasings or
could we normalize on a single term?

Section 7.3.3

  If no proxy is applicable, a typical client will invoke a handler
  routine, usually specific to the target URI's scheme, to connect
  directly to an origin for the target resource.  How that is
  accomplished is dependent on the target URI scheme and defined by its
  associated specification.

This document is the relevant specification for the "http" and "https"
URI schemes; a section reference to the corresponding procedures might
be in order.

Section 8.8.2.1

  An origin server with a clock MUST NOT send a Last-Modified date that
  is later than the server's time of message origination (Date).  If

I suspect some relevant details for this clock are covered in §10.2.2;
maybe a forward reference would be useful.

Section 10.2

  The remaining response header fields provide more information about
  the target resource for potential use in later requests.

I didn't see a previous enumeration of fields such that "remaining" would have
meaning.
(Also, the whole toplevel section seems to contain multiple sentences that are
nearly redundant.)

Section 10.2.2

  A recipient with a clock that receives a response message without a
[...]
  A recipient with a clock that receives a response with an invalid

Are we using "with a clock" as shorthand for "have a clock capable of
providing a reasonable approximation of the current instant in
Coordinated Universal Time"?  It might be worth clarifying if this
different phrasing than above is intended to convey different semantics.

Section 11.7.3

  The Proxy-Authentication-Info response header field is equivalent to
  Authentication-Info, except [...]

Is it worth calling out again that it can be sent as a trailer field, in
case someone specifically goes searching for trailer fields?

Section 13.2.1

  server that can provide a current representation.  Likewise, a server
  MUST ignore the conditional request header fields defined by this
  specification when received with a request method that does not
  involve the selection or modification of a selected representation,
  such as CONNECT, OPTIONS, or TRACE.

We do say "can be used with any method" regarding If-Match, earlier,
which is not very well aligned with this "MUST ignore".

Section 15.4

  5.  If the request method has been changed to GET or HEAD, remove
      content-specific header fields, including (but not limited to)
      Content-Encoding, Content-Language, Content-Location,
      Content-Type, Content-Length, Digest, ETag, Last-Modified.

The discussion in §8.8.3 seems to indicate that ETag is only used in
responses, not requests, so I'm not sure in what scenarios it would need
to be removed from the redirected request.

      |  *Note:* In HTTP/1.0, the status codes 301 (Moved Permanently)
      |  and 302 (Found) were defined for the first type of redirect
      |  ([RFC1945], Section 9.3).  Early user agents split on whether
      |  the method applied to the redirect target would be the same as
      |  the original request or would be rewritten as GET.  Although
      |  HTTP originally defined the former semantics for 301 and 302
      |  (to match its original implementation at CERN), and defined 303
      |  (See Other) to match the latter semantics, prevailing practice
      |  gradually converged on the latter semantics for 301 and 302 as
      |  well.  The first revision of HTTP/1.1 added 307 (Temporary
      |  Redirect) to indicate the former semantics of 302 without being
      |  impacted by divergent practice.  For the same reason, 308
      |  (Permanent Redirect) was later on added in [RFC7538] to match
      |  301.  [...]

I had to read this text several times to find a way to understand it
that seems to make sense to me (but might still be wrong!).
I think part of my confusion is that the word "former" is being used in
two different senses (the first of the two choices, and the
historical/earlier version).  Perhaps it's more clear to just talk about
"method rewriting" (and not rewriting) instead of using the overloaded
term.
=====END PREVIOUS COMMENT SECTION=====
2021-07-25
17 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from Discuss
2021-07-25
17 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-07-25
17 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-07-25
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-07-25
17 Julian Reschke New version available: draft-ietf-httpbis-semantics-17.txt
2021-07-25
17 (System) New version approved
2021-07-25
17 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-07-25
17 Julian Reschke Uploaded new revision
2021-06-17
16 (System) Changed action holders to Roy Fielding, Mark Nottingham, Julian Reschke, Francesca Palombini (IESG state changed)
2021-06-17
16 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-06-17
16 Robert Wilton
[Ballot comment]
Apologies but I have not been able to fully review the entire draft!

However, I would like to thank the authors and WG …
[Ballot comment]
Apologies but I have not been able to fully review the entire draft!

However, I would like to thank the authors and WG on the time and effort they have put into updating the HTTP specs which will make it much easier for HTTP implementers to check that they are up to date with the spec.

In my light reading of the doc, I did notice a few minor nits, which I will leave to the authors/WG to decide whether they wish to address:

  2.5.  Protocol Version

  HTTP's major version number is incremented when an incompatible
  message syntax is introduced.  The minor number is incremented when
  changes made to the protocol have the effect of adding to the message
  semantics or implying additional capabilities of the sender.

It is perhaps fairly obvious, but do you want to say that
the minor version number is reset to 0 when the major version number is incremented?


4.2.3.  http(s) Normalization and Comparison

  Two HTTP URIs that are equivalent after normalization (using any
  method) can be assumed to identify the same resource, and any HTTP
  component MAY perform normalization.  As a result, distinct resources
  SHOULD NOT be identified by HTTP URIs that are equivalent after
  normalization (using any method defined in Section 6.2 of [RFC3986]).
 
With the text in this section (4.2.3), I found it a bit unclear as to whether this normative text included the additional rules that were listed after it.  My assumption
is that they must, but I wasn't sure that the text was
that clear on this point.


9.2.1.  Safe Methods

    "crash the server"
   
Flagging in case you want to express this differently (e.g., cause the server to fail)


9.2.3.  Methods and Caching

  This specification defines caching semantics for GET, HEAD, and POST,
  although the overwhelming majority of cache implementations only
  support GET and HEAD.
 
It is somewhat ambiguous as to which specification is being referred to by "This".  Is it the semantics draft of the caching draft?
2021-06-17
16 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-06-16
16 Murray Kucherawy
[Ballot comment]
I regret that I haven't finished my review prior to the telechat.  I'll try to get my proper ballot in before Benjamin's DISCUSS …
[Ballot comment]
I regret that I haven't finished my review prior to the telechat.  I'll try to get my proper ballot in before Benjamin's DISCUSS is resolved, or at least before the approval is processed.
2021-06-16
16 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2021-06-16
16 Benjamin Kaduk
[Ballot discuss]
Thank you for this quite masterfully done mammoth undertaking!  I expect
to ballot Yes pending discussion of one point.

I'm looking at the …
[Ballot discuss]
Thank you for this quite masterfully done mammoth undertaking!  I expect
to ballot Yes pending discussion of one point.

I'm looking at the following text in Section 4.3.4 relating to how to
handle certificate validation failures for https:

  If the certificate is not valid for the URI's origin server, a user
  agent MUST either notify the user (user agents MAY give the user an
  option to continue with the connection in any case) or terminate the
  connection with a bad certificate error.  [...]

Given the discussion up in §3.5 about requirements to "notify" the user
vs requiring "confirmation" from the user, I don't think that just "MUST
notify the user" is sufficient to prevent the user-agent from
continuing, since it is sufficient to just write a log entry as the
means to notify the user.  Is the intent to require confirmation of the
action to continue in the face of such an error (which, again per §3.5
could be a pre-configured confirmation)?  An intent to require
"confirmation" (vs mere "notification") seems consistent with the
subsequent text placing requirements on automated clients and would be
more consistent with my understanding of general IETF consensus for
securing protocols
2021-06-16
16 Benjamin Kaduk
[Ballot comment]
I made some editorial suggestions in a pull request at
https://github.com/httpwg/http-core/pull/870 .

This document updates RFC 3864, which is part of BCP …
[Ballot comment]
I made some editorial suggestions in a pull request at
https://github.com/httpwg/http-core/pull/870 .

This document updates RFC 3864, which is part of BCP 90.
However, this document is targeting Proposed Standard status, which
means it cannot become a part of BCP 90 as part of that update.
Did we consider splitting out the RFC 3864 updates into a separate,
BCP-level, document, that would become part of BCP 90?

Section 1.2

  HTTP/2 ([RFC7540]) introduced a multiplexed session layer on top of
  the existing TLS and TCP protocols for exchanging concurrent HTTP
  messages with efficient field compression and server push.  HTTP/3
  ([HTTP3]) provides greater independence for concurrent messages by
  using QUIC as a secure multiplexed transport over UDP instead of TCP.

My understanding was that h2 and h3 also use non-text-based headers, in
contrast to HTTP/1.1's "text-based messaging syntax" that we mention
earlier.  Is that non-text nature worth noting here?

Section 3.7

                                Proxies are often used to group an
  organization's HTTP requests through a common intermediary for the
  sake of security, annotation services, or shared caching.  [...]

The term "security" can mean so many different things to different
audiences that its meaning in isolation is pretty minimal.  I suggest
finding a more specific term for the intended usage, perhaps relating to
an auditing, exfiltration protection, and/or content-filtering function.

  For example, an _interception proxy_ [RFC3040] (also commonly known
  as a _transparent proxy_ [RFC1919]) differs from an HTTP proxy
  because it is not chosen by the client.  Instead, an interception
  proxy filters or redirects outgoing TCP port 80 packets (and
  occasionally other common port traffic).  Interception proxies are
  commonly found on public network access points, as a means of
  enforcing account subscription prior to allowing use of non-local
  Internet services, and within corporate firewalls to enforce network
  usage policies.

Is this text still accurate in the era of https-everywhere and Let's
Encrypt?

Section 3.9

As Éric notes, OpenSSL 0.9.7l supports only SSL and TLSv1.0, which per
RFC 8996 is no longer permitted -- I concur with his recommendation to
update the example (potentially including Last-Modified).

Section 4.2.x

  The hierarchical path component and optional query component identify
  the target resource within that origin server's name space.

Would a BCP 190 reference be appropriate here (emphasizing that the name
space belongs to the origin server)?

Section 4.2.2

  The "https" URI scheme is hereby defined for minting identifiers
  within the hierarchical namespace governed by a potential origin
  server listening for TCP connections on a given port and capable of
  establishing a TLS ([RFC8446]) connection that has been secured for
  HTTP communication.  [...]

Is "capable" the correct prerequisite, or does the server need to
actually do so on that port?  (Given the following definition of
"secured", though, the ability to successfully do so would seem to
depend on the trust anchor configuration on the client, which is not
really something the server can control...)

Section 4.3.3

  Note, however, that the above is not the only means for obtaining an
  authoritative response, nor does it imply that an authoritative
  response is always necessary (see [Caching]).

Is it intentional that this paragraph diverges from the analogous
content in §4.3.2 (which also mentions Alt-Svc and other protocols
"outside the scope of this document")?

Section 5.3

      |  *Note:* In practice, the "Set-Cookie" header field ([RFC6265])
      |  often appears in a response message across multiple field lines
      |  and does not use the list syntax, violating the above
      |  requirements on multiple field lines with the same field name.
      |  Since it cannot be combined into a single field value,
      |  recipients ought to handle "Set-Cookie" as a special case while
      |  processing fields.  (See Appendix A.2.3 of [Kri2001] for
      |  details.)

The reference seems to conclude only that the situation for "Set-Cookie"
is underspecified, and doesn't really give me much guidance on what to
do if I receive a message with multiple field lines for "Set-Cookie".
(It does talk about the "Cookie" field and how semicolon is used to
separate cookie values, which implies that "Cookie" would get special
treatment to use semicolon to join field lines, but doesn't really give
me the impression that "Set-Cookie" should also have such treatment.)

Section 5.4

  A client MAY discard or truncate received field lines that are larger
  than the client wishes to process if the field semantics are such
  that the dropped value(s) can be safely ignored without changing the
  message framing or response semantics.

Is it worth saying anything about fields that the client does not
recognize?  (Per the previous discussion, the server needs to either
know that the client recognizes the field or only send fields that are
safe to ignore if unrecognized, if I understand correctly...)

Section 6.4.1

  In a response, the content's purpose is defined by both the request
  method and the response status code (Section 15).  For example, the
  content of a 200 (OK) response to GET (Section 9.3.1) represents the
  current state of the target resource, as observed at the time of the
  message origination date (Section 10.2.2), whereas the content of the
  same status code in a response to POST might represent either the
  processing result or the new state of the target resource after
  applying the processing.

Doesn't the last clause mean that there is some additional (meta)data
that can affect the content's purpose (e.g., a Content-Location field)?
Or how else would one know if the 200 POST response is the processing
result vs the new state?  It seems incomplete to just say "is defined by
both" and list only method and status code as the defining factors.

Section 7.6.3

[I had the same question as Martin Duke about default *TCP* port, and
the interaction with the scheme.  I see that it has been answered since
I initially drafted these notes, hooray.]

Section 7.7

  A proxy MUST NOT modify the "absolute-path" and "query" parts of the
  received target URI when forwarding it to the next inbound server,
  except as noted above to replace an empty path with "/" or "*".

I found where (in the discussion of normalization in §4.2.3) we say to
replace the empty path with "/" for non-OPTIONS requests.  I couldn't
find anywhere "above" where it was noted to replace an empty path with
"*" (presumably, for the OPTIONS requests), though.

Section 8.3

                          Implementers are encouraged to provide a means
  to disable such sniffing.

"encouraged to provide a means to disable" could be read as also
encouraging implementation of the (sniffing) mechanism itself.  Is it
actually the case that we encourage implementation of MIME sniffing?

Section 8.8.1

                                                                  A
  strong validator is unique across all versions of all representations
  associated with a particular resource over time.  [...]

My understanding is that, e.g., a cryptographic hash over the
representation and metadata would be intended to be a strong validator,
but for such a construction the "unique" property can only be guaranteed
probabilistically.  Are we comfortable with this phrasing that implies
an absolute requirement?

Section 8.8.4

  *  SHOULD send the Last-Modified value in non-subrange cache
      validation requests (using If-Modified-Since) if only a Last-
      Modified value has been provided by the origin server.

  *  MAY send the Last-Modified value in subrange cache validation
      requests (using If-Unmodified-Since) if only a Last-Modified value
      has been provided by an HTTP/1.0 origin server.  The user agent
      SHOULD provide a way to disable this, in case of difficulty.

I'm failing to come up with an explanation for why it's important to
specifically call out the HTTP/1.0 origin server in the latter case.
What's special about an HTTP/1.1 origin server that only provided a
Last-Modified value and subrange cache validation requests that makes
the MAY inapplicable?  (What's the actual expected behavior for that
situation?)

Section 9.2.2

  A request method is considered _idempotent_ if the intended effect on
  the server of multiple identical requests with that method is the
  same as the effect for a single such request.  [...]

I sometimes worry that a definition of idempotent like this hides the
interaction of repeated idempotent requests with other requests
modifying the same resource.  A+A is equivalent to A, but A+B+A is often
not equivalent to A+B...

Section 9.3.5

  Likewise, other implementation aspects of a resource might need to be
  deactivated or archived as a result of a DELETE, such as database or
  gateway connections.  In general, it is assumed that the origin
  server will only allow DELETE on resources for which it has a
  prescribed mechanism for accomplishing the deletion.

The specific phrasing of "only allow DELETE [...]" calls to mind (for
me) an expectation of authorization checks as well.  In some sense this
is no different than for POST or PUT, and thus may not be worth
particular mention here, but I thought I'd ask whether it makes sense to
mention authorization (and authentication).

  A client SHOULD NOT generate content in a DELETE request.  Content
  received in a DELETE request has no defined semantics, cannot alter
  the meaning or target of the request, and might lead some
  implementations to reject the request.

We had a similar paragraph earlier in the discussion of GET and HEAD,
but those paragraphs included a clause about "close the connection
because of its potential as a request smuggling attack" -- is DELETE not
at risk of use for request smuggling?

Section 10.1.1

  *  A server that responds with a final status code before reading the
      entire request content SHOULD indicate whether it intends to close
      the connection (e.g., see Section 9.6 of [Messaging]) or continue
      reading the request content.

The referenced section seems to cover the "close" connection option,
which is a positive signal of intent to close.  Is the absence of that
connection option to be interpreted as a positive signal of intent to
continue reading the request content, or is there some other positive
signal of such intent to continue reading?

Section 10.1.2

  A server SHOULD NOT use the From header field for access control or
  authentication.

It seems that the level of security provided by the From header field is
at most that of a bearer token, and that the natural choice of such
token is easily guessable (though unguessable choices are possible).
I'm having a hard time coming up with an IETF-consensus scenario where
it would make sense to use From for access control or authentication
(i.e., could this be MUST NOT instead?).

Section 10.1.3

                Some servers use the Referer header field as a means of
  denying links from other sites (so-called "deep linking") or
  restricting cross-site request forgery (CSRF), but not all requests
  contain it.

I think we should say something about the effectiveness of Referer
checks as a CSRF mitigation mechanism.

                        Most general-purpose user agents do not send the
  Referer header field when the referring resource is a local "file" or
  "data" URI.  A user agent SHOULD NOT send a Referer header field if

This seems like a curious statement.  Are we expecting future
general-purpose user agents to emulate this behavior?  If so, then why
not recommend it explicitly?

  the referring resource was accessed with a secure protocol and the
  request target has an origin differing from that of the referring
  resource, unless the referring resource explicitly allows Referer to
  be sent.  A user agent MUST NOT send a Referer header field in an

How does a referring resource indicate that Referer should be sent?

Section 10.1.4

  The TE field value consists of a list of tokens, each allowing for
  optional parameters (except for the special case "trailers").

Should the prose mention the 'weight' part of the t-codings construction
(the "weight" production itself does not seem to be defined until §11.4.2)?

Section 10.1.5

  For example, a sender might indicate that a message integrity check
  will be computed as the content is being streamed and provide the
  final signature as a trailer field.  This allows a recipient to

Please pick one of "message integrity check" and "signature" and use it
consistently; these are both cryptographic terms of art (with different
meanings).

  Because the Trailer field is not removed by intermediaries, it can
  also be used by downstream recipients to discover when a trailer
  field has been removed from a message.

It seems that this usage is only possible if sending the Trailer field is a
binding commitment to emit the relevant trailer fields; otherwise the
recipient cannot distinguish between a removal by an intermediary and a sender
declining to generate the trailer field.

Section 10.1.6

        A user agent SHOULD send a User-Agent header field in each
  request unless specifically configured not to do so.

(I assume that a reference to client-hints (or UA-CH) was considered and
rejected.)

  A user agent SHOULD NOT generate a User-Agent header field containing
  needlessly fine-grained detail and SHOULD limit the addition of
  subproducts by third parties.  Overly long and detailed User-Agent
  field values increase request latency and the risk of a user being
  identified against their wishes ("fingerprinting").

client-hints might even be more appropriate as a reference here than it
would be above...or just in §17.13.

Section 10.2

It seems like it might be worth listing the fields already defined in the
previous section (as request context fields) that can also appear as response
context fields.

Section 12.2

  Reactive negotiation suffers from the disadvantages of transmitting a
  list of alternatives to the user agent, which degrades user-perceived
  latency if transmitted in the header section, and needing a second
  request to obtain an alternate representation.  Furthermore, this
  specification does not define a mechanism for supporting automatic
  selection, though it does not prevent such a mechanism from being
  developed as an extension.

I'm not sure that I understand how an HTTP extension would help specify
a mechanism for automatic selection in reactive negotiation; isn't this
just an implementation detail in the user-agent?

Section 12.5.1

      |  *Note:* Use of the "q" parameter name to control content
      |  negotiation is due to historical practice.  Although this
      |  prevents any media type parameter named "q" from being used
      |  with a media range, such an event is believed to be unlikely
      |  given the lack of any "q" parameters in the IANA media type
      |  registry and the rare usage of any media type parameters in
      |  Accept.  Future media types are discouraged from registering
      |  any parameter named "q".

This note seems like it would be more useful in the IANA media-types
registry than "some random protocol specification that uses media
types".

Section 12.5.3

  For example,

  Accept-Encoding: compress, gzip
  Accept-Encoding:
  Accept-Encoding: *
  Accept-Encoding: compress;q=0.5, gzip;q=1.0
  Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Are these supposed to be multiple standalone examples or one single example with
multiple field lines?  (I note that they appear in a single
element in the XML source.)  If they are supposed to be one single
example, I would have expected some remark about the combination of "*"
and "*;q=0" (my understanding is that the q=0 renders codings not listed
as unacceptable, even despite the implicitly q=1 wildcard).
It seems that in other instances where we provide multiple examples in
a single artwork, the prefacing text is "Examples:" plural, that makes
some effort to disambiguate.

      |  *Note:* Most HTTP/1.0 applications do not recognize or obey
      |  qvalues associated with content-codings.  This means that
      |  qvalues might not work and are not permitted with x-gzip or
      |  x-compress.

This wording implies to me that there is a normative requirement
somewhere else that qvalues cannot be used with x-gzip and x-compress,
but I'm not sure where that would be.  (It's also a bit hard to
understand how x-gzip would be affected but not plain gzip, given that
§18.6 lists it as an alias for gzip ... additional restrictions don't
quite match up with an "alias" nature.)

Section 12.5.4

  It might be contrary to the privacy expectations of the user to send
  an Accept-Language header field with the complete linguistic
  preferences of the user in every request (Section 17.13).

This leaves me wondering how to improve on the situation and pick which
subset of requests to send the header field in.  I would expect that a
blind random sampling approach would not yield privacy improvements over
always sending them.

Section 12.5.5

  An origin server SHOULD send a Vary header field when its algorithm
  for selecting a representation varies based on aspects of the request
  message other than the method and target URI, unless the variance
  cannot be crossed or the origin server has been deliberately
  configured to prevent cache transparency.  [...]

I don't think I know what it means to "cross" a variance.  The example
(elided from this comment) about Authorization not needing to be
included gives some hint as to what is meant, but I still don't have a
clear picture.

Section 13.2.2

  5.  When the method is GET and both Range and If-Range are present,
      evaluate the If-Range precondition:

      *  if the validator matches and the Range specification is
          applicable to the selected representation, respond 206
          (Partial Content)

  6.  Otherwise,

      *  all conditions are met, so perform the requested action and
          respond according to its success or failure.

I think that if the If-Range doesn't match, we're supposed to ignore the
Range header field when performing the requested action, which doesn't
seem to match up with this unadorned directive to "perform the requested
action" (which would include the Range header field).
(We might also change point (5) to use the "if true" phrasing that the
other items use in the context of evaluating the precondition.)

Section 15.4.9

      |  *Note:* This status code is much younger (June 2014) than its
      |  sibling codes, and thus might not be recognized everywhere.
      |  See Section 4 of [RFC7538] for deployment considerations.

This document obsoletes RFC 7538; if we believe that content is still
useful we should probably consider incorporating it into this document.

Section 16.3.1

  Field names are registered on the advice of a Designated Expert
  (appointed by the IESG or their delegate).  Fields with the status
  'permanent' are Specification Required ([RFC8126], Section 4.6).

I would have expected IANA to ask for the phrase "Expert Review" to be
used for the general case (if they did not already), since that's the
relevant registration policy defined in RFC 8126.

  Registration requests consist of at least the following information:
[...]
  Specification document(s):
      Reference to the document that specifies the field, preferably

If the registration consists of "at least" a group of information that
includes a specification document, doesn't that mean the policy is
*always* "Specification Required", not just for permanent registrations?

  Provisional entries can be removed by the Expert(s) if - in
  consultation with the community - the Expert(s) find that they are
  not in use.  The Experts can change a provisional entry's status to
  permanent at any time.

(The ability to freely convert a provisional registration to permanent
seems to also require a specification document to always be present,
even for provisional registrations.)

Section 17

A few potential considerations that don't seem to be mentioned in the
subsections:

- Implementation divergence in handling multi-member field values when
  singletons are expected, could lead to security issues (in a similar
  vein as how request smuggling works)

- Though ETag is formally opaque to clients, any internal structure to
  the values could still be inspected and attacked by a malicious
  client.  We might consider giving guidance that ETag values should
  be unpredictable.

- When the same information is present at multiple protocol layers
  (e.g., the transport port number and the Host field value), in the
  general case, attacks are possible if there is not check for
  consistency of the values in the different layers.  It's often helpful
  to provide guidance on which entit(ies) should perform the check, to
  avoid scenarios where all parties are expecting "someone else" to do
  it.

- Relatedly, the port value is part of the https "origin" concept, but is not
  authenticated by the certificate and could be modified (in the
  transport layer) by an on-path attacker.  The safety of per-origin
  isolation relies on the server to check that the port intended by the
  client matches the port the request was actually received on.

- We mention that in response to some 3xx redirection responses, a
  client capable of link editing might do so automatically.  Doing so
  for http-not-s responses would allow for a form of privilege
  escalation, converting even a temporary access into more permanent
  changes on referring resources.

- We make heavy use of URIs and URI components; referencing the security
  considerations of RFC 3986 might be worthwhile

Section 17.1

  Unfortunately, communicating authority to users can be difficult.
  For example, _phishing_ is an attack on the user's perception of
  authority, where that perception can be misled by presenting similar
  branding in hypertext, possibly aided by userinfo obfuscating the
  authority component (see Section 4.2.1).  [...]

We might also mention "confusable" domain names here as well (which are
possible even without resorting to IDNs).

Section 17.5

Should we also discuss situations where there might be redundant lengths
at different encoding layers (e.g., HTTP framing and MIME multipart
boundaries), in a similar vein to
https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34#section-10.8
?

Section 17.16.3

  Authentication schemes that solely rely on the "realm" mechanism for
  establishing a protection space will expose credentials to all
  resources on an origin server.  [...]

There's also not any clear authorization mechanism for the origin to claim
use of a given realm value, which can lead to the client sending
credentials for the claimed realm without knowing that the server should
be receiving such credentials.

Section 19.2

Should RFC 5322 be normative?  We rely on it for, e.g., the "mailbox"
ABNF construction.

Appendix A

[Just noting that I did not attempt to validate the ABNF, since the
shepherd writeup notes that they have been validated]

Appendix B.4

  Clarified that If-Unmodified-Since doesn't apply to a resource
  without a concept of modification time.  (Section 13.1.4)

I couldn't really locate which text was supposed to be providing this
clarification.


NITS

Section 3.1

                                              Most resources are
  identified by a Uniform Resource Identifier (URI), as described in
  Section 4.
[...]
  HTTP relies upon the Uniform Resource Identifier (URI) standard
  [RFC3986] to indicate the target resource (Section 7.1) and
  relationships between resources.

Are these two statements compatible?  (What is used for the non-URI
resource identification scenarios?)

Section 5.5

We seem to use the obs-text ABNF construction prior to its definition,
which is in Section 5.6.4.

Section 5.6.1.1

  In any production that uses the list construct, a sender MUST NOT
  generate empty list elements.  In other words, a sender MUST generate
  lists that satisfy the following syntax:

    1#element => element *( OWS "," OWS element )

Are the two formulations equivalent without some restriction on
'element' itself?

Section 6.4.2

  2.  If the request method is GET and the response status code is 200
      (OK), the content is a representation of the resource identified
      by the target URI (Section 7.1).

  3.  If the request method is GET and the response status code is 203
      (Non-Authoritative Information), the content is a potentially
      modified or enhanced representation of the target resource as
      provided by an intermediary.

  4.  If the request method is GET and the response status code is 206
      (Partial Content), the content is one or more parts of a
      representation of the resource identified by the target URI
      (Section 7.1).

  5.  If the response has a Content-Location header field and its field
      value is a reference to the same URI as the target URI, the
      content is a representation of the target resource.

I count two "target resource" and two "resource identified by the target
URI".  Is there an important distinction between those two phrasings or
could we normalize on a single term?

Section 7.3.3

  If no proxy is applicable, a typical client will invoke a handler
  routine, usually specific to the target URI's scheme, to connect
  directly to an origin for the target resource.  How that is
  accomplished is dependent on the target URI scheme and defined by its
  associated specification.

This document is the relevant specification for the "http" and "https"
URI schemes; a section reference to the corresponding procedures might
be in order.

Section 8.8.2.1

  An origin server with a clock MUST NOT send a Last-Modified date that
  is later than the server's time of message origination (Date).  If

I suspect some relevant details for this clock are covered in §10.2.2;
maybe a forward reference would be useful.

Section 10.2

  The remaining response header fields provide more information about
  the target resource for potential use in later requests.

I didn't see a previous enumeration of fields such that "remaining" would have
meaning.
(Also, the whole toplevel section seems to contain multiple sentences that are
nearly redundant.)

Section 10.2.2

  A recipient with a clock that receives a response message without a
[...]
  A recipient with a clock that receives a response with an invalid

Are we using "with a clock" as shorthand for "have a clock capable of
providing a reasonable approximation of the current instant in
Coordinated Universal Time"?  It might be worth clarifying if this
different phrasing than above is intended to convey different semantics.

Section 11.7.3

  The Proxy-Authentication-Info response header field is equivalent to
  Authentication-Info, except [...]

Is it worth calling out again that it can be sent as a trailer field, in
case someone specifically goes searching for trailer fields?

Section 13.2.1

  server that can provide a current representation.  Likewise, a server
  MUST ignore the conditional request header fields defined by this
  specification when received with a request method that does not
  involve the selection or modification of a selected representation,
  such as CONNECT, OPTIONS, or TRACE.

We do say "can be used with any method" regarding If-Match, earlier,
which is not very well aligned with this "MUST ignore".

Section 15.4

  5.  If the request method has been changed to GET or HEAD, remove
      content-specific header fields, including (but not limited to)
      Content-Encoding, Content-Language, Content-Location,
      Content-Type, Content-Length, Digest, ETag, Last-Modified.

The discussion in §8.8.3 seems to indicate that ETag is only used in
responses, not requests, so I'm not sure in what scenarios it would need
to be removed from the redirected request.

      |  *Note:* In HTTP/1.0, the status codes 301 (Moved Permanently)
      |  and 302 (Found) were defined for the first type of redirect
      |  ([RFC1945], Section 9.3).  Early user agents split on whether
      |  the method applied to the redirect target would be the same as
      |  the original request or would be rewritten as GET.  Although
      |  HTTP originally defined the former semantics for 301 and 302
      |  (to match its original implementation at CERN), and defined 303
      |  (See Other) to match the latter semantics, prevailing practice
      |  gradually converged on the latter semantics for 301 and 302 as
      |  well.  The first revision of HTTP/1.1 added 307 (Temporary
      |  Redirect) to indicate the former semantics of 302 without being
      |  impacted by divergent practice.  For the same reason, 308
      |  (Permanent Redirect) was later on added in [RFC7538] to match
      |  301.  [...]

I had to read this text several times to find a way to understand it
that seems to make sense to me (but might still be wrong!).
I think part of my confusion is that the word "former" is being used in
two different senses (the first of the two choices, and the
historical/earlier version).  Perhaps it's more clear to just talk about
"method rewriting" (and not rewriting) instead of using the overloaded
term.
2021-06-16
16 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2021-06-16
16 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2021-06-16
16 Warren Kumari
[Ballot comment]
Like Martin I learnt HTTP though osmosis - although "learnt" might be overselling it. Perhaps "randomly searched stack-overflow for some related words" would …
[Ballot comment]
Like Martin I learnt HTTP though osmosis - although "learnt" might be overselling it. Perhaps "randomly searched stack-overflow for some related words" would be a better description.
When I saw initially saw the length of this document I was somewhere between apprehensive and distraught, but I figured that I'd get some revenge by providing lots and lots of nitty comments that you'd have to address... but, apparently, I was thwarted in that. There is very little for me to complain about, and others have already done so, so.... um...

2021-06-16
16 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-06-16
16 Zaheduzzaman Sarker
[Ballot comment]
Big thanks to editors and contributors of the this document.

I found this document to be very well written with right level of …
[Ballot comment]
Big thanks to editors and contributors of the this document.

I found this document to be very well written with right level of description which surely makes the developer's life a bit easier, specially having all the important considerations and recommendations in one place.

I have following observations -

* Server push is mentioned in section 1.2. I was expecting some descriptions in this document on how the server push is realized specially using the methods defined in this document.

* Section 4.2.2:  it says-

          "The origin server for an "https" URI is identified by the authority
  component, which includes a host identifier and optional port number
  ([RFC3986], Section 3.2.2).  If the port subcomponent is empty or not
given, TCP port 443 (the reserved port for HTTP over TLS) is the
  default.  "
     
      how does this default work with HTTP/3 which used UDP port 443?

* It felt like security consideration section missing considerations for the TRACE method.  The section 9.3.8 says - "A client MUST NOT generate fields in a TRACE request containing sensitive data" , I am just wondering is that good enough warning.

* I support Roman's comment about the strength of the recommendation based on the use of the verb “ought”. This might be a bit more confusing to the readers with non-native English language background. I would suggest to use more recommend or should or must in the entire document instead of "ought to".

* Lars provided very good input on editorial fixes/nits, I would skip mine and hope his will be addressed by the editors.
2021-06-16
16 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-06-16
16 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2021-06-14
16 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-06-12
16 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2021-06-11
16 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Martin Duke wrote a nice sentence that fits my experience with this document: "As …
[Ballot comment]
Thank you for the work put into this document.

Martin Duke wrote a nice sentence that fits my experience with this document: "As someone who has learned HTTP via osmosis, it was very helpful to finally read it all collected in one place".

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Is there any reason why the 'Forwarded' header (RFC 7239) is not listed ?


-- Section 3.3 --
"As a result, a server MUST NOT assume that two requests ..." unsure about the use of "as a result" as this paragraph is not really a conclusion of the previous §. Suggest to remove "As a result".

-- Section 3.9 --
Strongly suggest to update the example by avoiding OpenSSL/0.9.71 as its TLS version is probably insecure (or even historic) ;-)

-- Section 4.3.3 --
2nd and 3rd § differ as it seems that only H/2 and H/3 accept cert with several entries. AFAIK, H/1 also accepts several subject names in on cert.

3rd § I am afraid that the meaning of the text about DNS query has completely escaped me :-(

-- Section 4.3.4 --
Should there be a reference to "CN-ID" ?

-- Section 4.3.5 --
I quickly read the relevant sections of RFC 3986 and RFC 5280 but I cannot find the information on whether 1/ IPv6 link-local 2/ IPv6 ULA addresses are valid and how to verify them. Should there some text in this section ?

== NITS ==

-- Section 7.2 --
References to H/2 and H/3 have previously be given, no need to repeat ?
2021-06-11
16 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-06-11
16 Lars Eggert
[Ballot comment]
Dale Worley's GenART review hasn't been responded to yet.

Section 3. , paragraph 2, comment:
>    HTTP was created for the World …
[Ballot comment]
Dale Worley's GenART review hasn't been responded to yet.

Section 3. , paragraph 2, comment:
>    HTTP was created for the World Wide Web (WWW) architecture and has
>    evolved over time to support the scalability needs of a worldwide
>    hypertext system.  Much of that architecture is reflected in the

Given the degree to which HTTP is now used a a transport for things other than
the HTML web, the last part of this sentence seems dated.

Section 5.6.7. , paragraph 25, comment:
>    Recipients of a timestamp value in rfc850-date format, which uses a

Suggest to add an actual reference to RFC850.

Section 10.2.2. , paragraph 9, comment:
>    A recipient with a clock that receives a response with an invalid
>    Date header field value MAY replace that value with the time that
>    response was received.

"Invalid" as in not well-formed, or as in inaccurate?

Possible DOWNREF from this Standards Track doc to [Welch]. If so, the IESG
needs to approve it.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"Table of Contents", paragraph 1, nit:
> Table of Contents

Not all section headings consistently use title case.

Section 1.2. , paragraph 4, nit:
>    HTTP/2 ([RFC7540]) introduced a multiplexed session layer on top of

It's unusual to put a reference (also) in parenthesis; suggest to remove the
parenthesis here and check similar occurrences throughout the document.

Section 3.8. , paragraph 2, nit:
>    requests.  Any client or server MAY employ a cache, though a cache
>    cannot be used while acting as a tunnel.

cannot -> MUST NOT?

Section 3.8. , paragraph 7, nit:
-    caching to optimise regional and global distribution of popular
-                    ^
+    caching to optimize regional and global distribution of popular
+                    ^

Section 5.6.7. , paragraph 2, nit:
-    implementations, all three are defined here.  The preferred format is
-                                                      ^^^^^^^^^
+    implementations, all three are defined here.  The RECOMMENDED format is
+                                                      ^^^^^^^^^^^

Section 5.6.7. , paragraph 4, nit:
-    An example of the preferred format is
-                      ^^^^^^^^^
+    An example of the RECOMMENDED format is
+                      ^^^^^^^^^^^

Section 5.6.7. , paragraph 10, nit:
-    Preferred format:
+  RECOMMENDED format:

Section 8.3.1. , paragraph 6, nit:
-    the first is preferred for consistency (the "charset" parameter value
-                ^^^^^^^^^
+    the first is RECOMMENDED for consistency (the "charset" parameter value
+                ^^^^^^^^^^^

Section 8.8.3. , paragraph 9, nit:
-    preferable to send Etag as a header field unless the entity-tag is
-    ^^^^^^^^^^
+    RECOMMENDED to send Etag as a header field unless the entity-tag is
+    ^^^^^^^^^^^

Section 8.8.4. , paragraph 6, nit:
-    In other words, the preferred behavior for an origin server is to
-                        ^^^^^^^^^
+    In other words, the RECOMMENDED behavior for an origin server is to
+                        ^^^^^^^^^^^

Section 11.6.1. , paragraph 10, nit:
-    Some user agents do not recognise this form, however.  As a result,
-                                  ^
+    Some user agents do not recognize this form, however.  As a result,
+                                  ^

Section 14.1.1. , paragraph 2, nit:
-    following gramar is generic: each range unit is expected to specify
+    following grammar is generic: each range unit is expected to specify
+                +

Section 15.5.5. , paragraph 2, nit:
-    permanent; the 410 (Gone) status code is preferred over 404 if the
-                                            ^^^^^^^^^
+    permanent; the 410 (Gone) status code is RECOMMENDED over 404 if the
+                                            ^^^^^^^^^^^

"B.2. ", paragraph 9, nit:
-    comma from the allowed set of charaters for a host name in received-
+    comma from the allowed set of characters for a host name in received-
+                                      +

Section 1.1. , paragraph 3, nit:
> sual to put a reference (also) in parenthesis; suggest to remove the parenth
>                                ^^^^^^^^^^^^^^
Did you mean "in parentheses"? "parenthesis" is the singular.

Section 1.1. , paragraph 3, nit:
> erence (also) in parenthesis; suggest to remove the parenthesis here and chec
>                              ^^^^^^^^^^^^^^^^^
The verb "suggest" is used with the gerund form.

Section 2.4. , paragraph 2, nit:
> the degree to which HTTP is now used a a transport for things other than the
>                                      ^^^
Two determiners in a row. Choose either "a" or "a".

Section 5.6.3. , paragraph 3, nit:
>  )) ; e.g., Jun 2 HTTP-date is case sensitive. Note that Section 4.2 of [Cach
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 5.6.4. , paragraph 4, nit:
>  describe and route the message, a headers lookup table of key/value pairs fo
>                                    ^^^^^^^
An apostrophe may be missing.

Section 5.6.4. , paragraph 6, nit:
> nbounded stream of content, and a trailers lookup table of key/value pairs f
>                                  ^^^^^^^^
An apostrophe may be missing.

Section 6.2. , paragraph 6, nit:
> located within a _trailer section_ are are referred to as "trailer fields" (o
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 7.3.2. , paragraph 2, nit:
> age with a field value that is the lesser of a) the received value decrement
>                                    ^^^^^^
Use "least", "lessest", "littlest" to express an extreme with this adjective.

Section 14.1. , paragraph 2, nit:
> n use three-digit integer values outside of that range (i.e., 600..999) for
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 14.4. , paragraph 8, nit:
> ubsections below, if the field would have been sent in a 200 (OK) response to
>                                ^^^^^^^^^^^^^^^
Did you mean "had been"?

Section 15.4. , paragraph 19, nit:
>  what (if any) content codings would have been accepted in the request. On t
>                                ^^^^^^^^^^^^^^^
Did you mean "had been"?

Section 16. , paragraph 1, nit:
> d. Registrations happen on a "First Come First Served" basis (see Section 4.4
>                                    ^^^^
It seems that a comma is missing.

Section 19.1. , paragraph 3, nit:
> Range units are compared in a case insensitive fashion. (Section 14.1) The p
>                              ^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Section 19.1. , paragraph 16, nit:
> ferring to RFC 723x. * Remove acknowledgements specific to RFC 723x. * Move
>                              ^^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Section 19.1. , paragraph 16, nit:
> pecific to RFC 723x. * Move "Acknowledgements" to the very end and make them
>                              ^^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

"Appendix A. ", paragraph 18, nit:
> s/6>) * In Section 16.6.1, advise to make new content codings self-descriptiv
>                                  ^^^^^^^
Did you mean "making"? Or maybe you should add a pronoun? In active voice,
"advise" + "to" takes an object, usually a pronoun.

"C.3. ", paragraph 1, nit:
> , RFC 7234, and RFC 7235. The acknowledgements within those documents still
>                              ^^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Uncited references: [RFC2145], [RFC7617], [RFC7234], [RFC2617].

Obsolete reference to RFC2145, obsoleted by RFC7230 (this may be on purpose).

Obsolete reference to RFC2068, obsoleted by RFC2616 (this may be on purpose).

These URLs point to tools.ietf.org, which is being deprecated:
* https://tools.ietf.org/html/draft-ietf-httpbis-messaging-16
* https://tools.ietf.org/html/draft-ietf-httpbis-cache-16
* https://tools.ietf.org/html/draft-ietf-quic-http-34

These URLs in the document can probably be converted to HTTPS:
* http://arxiv.org/abs/cs.SE/0105018
2021-06-11
16 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-06-10
16 Martin Duke
[Ballot comment]
As someone who has learned HTTP via osmosis, it was very helpful to finally read it all collected in one place. Thank you. …
[Ballot comment]
As someone who has learned HTTP via osmosis, it was very helpful to finally read it all collected in one place. Thank you. I especially appreciate the effort to document legacy undesirable behaviors, which implementers need to account for in their work.

(7.6.3) Via

"If a port is not provided, a recipient MAY interpret that as meaning it was received on the default TCP port, if any, for the received-protocol."

So if received-protocol is "3", it's a UDP port.

If received-protocol is "1" or "1.1", is the default port 80 or 443? IIUC the scheme isn't included to determine this.

(7.7) Message Transformations

"A proxy that transforms the content of a 200 (OK) response can inform downstream recipients that a transformation has been applied by changing the response status code to 203 (Non-Authoritative Information)"

Why not an normative word, instead of "can"?

(12.5.3) Is it correct that "identity" and having no field value for Accept-Encoding are synonymous?

"Servers that fail a request due to an unsupported content coding ought to respond with a 415 (Unsupported Media Type) status"

Why not s/ought to/SHOULD ?

(14.3) Why can only origin servers send "Accept-Ranges: bytes"? Why not intermediaries?

(15.3.7) "A sender that generates a 206 response with an If-Range header field"... (13.1.5) leads me to believe that only clients can send If-Range. So how can there be a response with If-Range?

(15.3.7.2) The last instance of THIS_STRING_SEPARATES has a trailing '--'. If this is intentional, it ought to be explained.

(16.3.1) says field names SHOULD begin with a letter, but (16.3.2.1) says they SHOULD begin with "an alphanumeric character". More broadly, the "Field name:" description in (16.3.1) should probably refer to (16.3.2.1) unless I'm misunderstanding the scope of these sections.

(17.13) s/TCP behavior/TCP or QUIC behavior

(B) It would be good to mention here that accept-ext has been removed in (12.5.1), and accept-charset is deprecated in (12.5.2), if that is new to this spec.
2021-06-10
16 Martin Duke [Ballot Position Update] New position, Yes, has been recorded for Martin Duke
2021-06-10
16 Roman Danyliw
[Ballot comment]
** Section 2.2.  Per “Additional (social) requirements are placed on implementations …”, what’s a “social” requirement?

** Section 4.2.2.

Resources made available via …
[Ballot comment]
** Section 2.2.  Per “Additional (social) requirements are placed on implementations …”, what’s a “social” requirement?

** Section 4.2.2.

Resources made available via the "https" scheme have no shared 
identity with the "http" scheme.  They are distinct origins with
  separate namespaces.  However, an extension to HTTP that is defined
  to apply to all origins with the same host, such as the Cookie
  protocol [RFC6265], can allow information set by one service to
  impact communication with other services within a matching group of
  host domains.

It would be worth reiterating that it might be risky for extensions to treat http + https origins on the same host uniformly. 

** Section 5.1.  Convention question.  Per “Field names … ought to be registered within the …” HTTP field name registry, I have a question about the strength of the recommendation based on the use of the verb “ought” – is that RECOMMENDED? SHOULD?  Section 8.3.1, 8.3.2, 8.4.1, 8.8.3, etc use a similar construct.

** Section 7.2.  Does this text allow for the possibility for both a Host and :authority be included?

** Section 9.2.1.  In addition to example of the access logs files filling the disk, there could be significant CPU load if the target is a script.

** Section 17.1.  The text provides helpful caution by stressing that “… the user's local name resolution    service [is used] to determine where it can find authoritative responses.  This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs.”  The subsequent text highlights DNSSEC as improving authenticity.  It seems that the integrity provided by DoT or DoH would also be relevant.

** Section 17.2

Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve this problem.

No disagreement with the sentiment, but I would recommend not framing it in term of the trustworthiness of the _people_ (i.e., intermediaries with poor security or privacy practices is not necessarily due to the lack of trustworthiness of the engineers operating the service; perhaps these services are also run in of jurisdictions where confidence in them should be reduced). 

NEW
Users need to be aware that intermediaries are no more trustworthy that the entities that operate them and the policies governing them; HTTP itself cannot solve this problem.

** Section 17.5.  More generically describe the attack

OLD
Failure to limit such processing can result in buffer overflows, arithmetic overflows, or increased vulnerability to
  denial-of-service attacks.

NEW
Failure to limit such processing can result in arbitrary code execution due to a buffer overflows or arithmetic overflows; or increased vulnerability to denial-of-service attacks.

** Editorial

-- Section 3.5.  Should s/advance configuration choices/advanced configuration choices/?

-- Section 4.2.2.
A client MUST ensure that its HTTP requests for an "https" resource
  are secured, prior to being communicated, and that it only accepts
  secured responses to those requests.  Note that the definition of
  what cryptographic mechanisms are acceptable to client and server are
  usually negotiated and can change over time.

This text goes from referring to “secured” in the first sentence to “[acceptable] cryptographic mechanisms” in the second sentence.  To link them, perhaps s/are secured/are cryptographically secured/

-- Section 6.5.  Typo. s/section_ are are/section_ are/

-- Section 11.1.  The text (at least when read as a .txt) isn’t showing RFC7617 or RFC7616 as references.

-- Section 14.1.1.  Typo. s/gramar/grammar/
2021-06-10
16 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2021-06-10
16 Francesca Palombini Ballot has been issued
2021-06-10
16 Francesca Palombini [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini
2021-06-10
16 Francesca Palombini Created "Approve" ballot
2021-06-10
16 Francesca Palombini IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2021-06-10
16 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-06-09
16 Dale Worley Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list.
2021-06-09
16 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2021-06-09
16 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-semantics-16. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-semantics-16. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that 13 registry actions will need to be completed upon approval of this document.

First, in the Uniform Resource Identifier (URI) Schemes registry at

https://www.iana.org/assignments/uri-schemes/

the following URI schemes will have their references changed:

URI Scheme: http
Template:
Description: Hypertext Transfer Protocol
Status: Permanent
Well-known URI Support: [RFC8615]
Reference: [ RFC-to-be; Section 4.2.1 ]
Notes:

URI Scheme: https
Template:
Description: Hypertext Transfer Protocol Secure
Status: Permanent
Well-known URI Support: [RFC8615]
Reference: [ RFC-to-be; Section 4.2.2 ]
Notes:

Second, in the Hypertext Transfer Protocol (HTTP) Method registry at

https://www.iana.org/assignments/http-methods/

the reference for the registry will be changed to Section 16.1.1 of this document and the following methods will be updated or (as in the case of "*") added:

Method: CONNECT
Safe: no
Idempotent: no
Reference: [ RFC-to-be; Section 9.3.6 ]

Method: DELETE
Safe: no
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.5 ]

Method: GET
Safe: yes
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.1 ]

Method: HEAD
Safe: yes
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.2 ]

Method: OPTIONS
Safe: yes
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.7 ]

Method: POST
Safe: no
Idempotent: no
Reference: [ RFC-to-be; Section 9.3.3 ]

Method: PUT
Safe: no
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.4 ]

Method: TRACE
Safe: yes
Idempotent: yes
Reference: [ RFC-to-be; Section 9.3.8 ]

Method: *
Safe: no
Idempotent: no
Reference: [ RFC-to-be; Section 18.2 ]

Third, in the Hypertext Transfer Protocol (HTTP) Status Code registry at

https://www.iana.org/assignments/http-status-codes/

the reference for the registry will be changed to Section 16.2.1 of this document and the following status codes will be updated or (as in the case of "(Unused)") added:

+=======+===============================+===============================+
| Value | Description | Reference |
+=======+===============================+===============================+
| 100 | Continue | [ RFC-to-be; Section 15.2.1 ] |
+-------+-------------------------------+-------------------------------+
| 101 | Switching Protocols | [ RFC-to-be; Section 15.2.2 ] |
+-------+-------------------------------+-------------------------------+
| 200 | OK | [ RFC-to-be; Section 15.3.1 ] |
+-------+-------------------------------+-------------------------------+
| 201 | Created | [ RFC-to-be; Section 15.3.2 ] |
+-------+-------------------------------+-------------------------------+
| 202 | Accepted | [ RFC-to-be; Section 15.3.3 ] |
+-------+-------------------------------+-------------------------------+
| 203 | Non-Authoritative Information | [ RFC-to-be; Section 15.3.4 ] |
+-------+-------------------------------+-------------------------------+
| 204 | No Content | [ RFC-to-be; Section 15.3.5 ] |
+-------+-------------------------------+-------------------------------+
| 205 | Reset Content | [ RFC-to-be; Section 15.3.6 ] |
+-------+-------------------------------+-------------------------------+
| 206 | Partial Content | [ RFC-to-be; Section 15.3.7 ] |
+-------+-------------------------------+-------------------------------+
| 300 | Multiple Choices | [ RFC-to-be; Section 15.4.1 ] |
+-------+-------------------------------+-------------------------------+
| 301 | Moved Permanently | [ RFC-to-be; Section 15.4.2 ] |
+-------+-------------------------------+-------------------------------+
| 302 | Found | [ RFC-to-be; Section 15.4.3 ] |
+-------+-------------------------------+-------------------------------+
| 303 | See Other | [ RFC-to-be; Section 15.4.4 ] |
+-------+-------------------------------+-------------------------------+
| 304 | Not Modified | [ RFC-to-be; Section 15.4.5 ] |
+-------+-------------------------------+-------------------------------+
| 305 | Use Proxy | [ RFC-to-be; Section 15.4.6 ] |
+-------+-------------------------------+-------------------------------+
| 306 | (Unused) | [ RFC-to-be; Section 15.4.7 ] |
+-------+-------------------------------+-------------------------------+
| 307 | Temporary Redirect | [ RFC-to-be; Section 15.4.8 ] |
+-------+-------------------------------+-------------------------------+
| 308 | Permanent Redirect | [ RFC-to-be; Section 15.4.9 ] |
+-------+-------------------------------+-------------------------------+
| 400 | Bad Request | [ RFC-to-be; Section 15.5.1 ] |
+-------+-------------------------------+-------------------------------+
| 401 | Unauthorized | [ RFC-to-be; Section 15.5.2 ] |
+-------+-------------------------------+-------------------------------+
| 402 | Payment Required | [ RFC-to-be; Section 15.5.3 ] |
+-------+-------------------------------+-------------------------------+
| 403 | Forbidden | [ RFC-to-be; Section 15.5.4 ] |
+-------+-------------------------------+-------------------------------+
| 404 | Not Found | [ RFC-to-be; Section 15.5.5 ] |
+-------+-------------------------------+-------------------------------+
| 405 | Method Not Allowed | [ RFC-to-be; Section 15.5.6 ] |
+-------+-------------------------------+-------------------------------+
| 406 | Not Acceptable | [ RFC-to-be; Section 15.5.7 ] |
+-------+-------------------------------+-------------------------------+
| 407 | Proxy Authentication Required | [ RFC-to-be; Section 15.5.8 ] |
+-------+-------------------------------+-------------------------------+
| 408 | Request Timeout | [ RFC-to-be; Section 15.5.9 ] |
+-------+-------------------------------+-------------------------------+
| 409 | Conflict | [ RFC-to-be; Section 15.5.10] |
+-------+-------------------------------+-------------------------------+
| 410 | Gone | [ RFC-to-be; Section 15.5.11] |
+-------+-------------------------------+-------------------------------+
| 411 | Length Required | [ RFC-to-be; Section 15.5.12] |
+-------+-------------------------------+-------------------------------+
| 412 | Precondition Failed | [ RFC-to-be; Section 15.5.13] |
+-------+-------------------------------+-------------------------------+
| 413 | Content Too Large | [ RFC-to-be; Section 15.5.14] |
+-------+-------------------------------+-------------------------------+
| 414 | URI Too Long | [ RFC-to-be; Section 15.5.15] |
+-------+-------------------------------+-------------------------------+
| 415 | Unsupported Media Type | [ RFC-to-be; Section 15.5.16] |
+-------+-------------------------------+-------------------------------+
| 416 | Range Not Satisfiable | [ RFC-to-be; Section 15.5.17] |
+-------+-------------------------------+-------------------------------+
| 417 | Expectation Failed | [ RFC-to-be; Section 15.5.18] |
+-------+-------------------------------+-------------------------------+
| 418 | (Unused) | [ RFC-to-be; Section 15.5.19] |
+-------+-------------------------------+-------------------------------+
| 421 | Misdirected Request | [ RFC-to-be; Section 15.5.20] |
+-------+-------------------------------+-------------------------------+
| 422 | Unprocessable Content | [ RFC-to-be; Section 15.5.21] |
+-------+-------------------------------+-------------------------------+
| 426 | Upgrade Required | [ RFC-to-be; Section 15.5.22] |
+-------+-------------------------------+-------------------------------+
| 500 | Internal Server Error | [ RFC-to-be; Section 15.6.1 ] |
+-------+-------------------------------+-------------------------------+
| 501 | Not Implemented | [ RFC-to-be; Section 15.6.2 ] |
+-------+-------------------------------+------------------------------+
| 502 | Bad Gateway | [ RFC-to-be; Section 15.6.3 ] |
+-------+-------------------------------+-------------------------------+
| 503 | Service Unavailable | [ RFC-to-be; Section 15.6.4 ] |
+-------+-------------------------------+-------------------------------+
| 504 | Gateway Timeout | [ RFC-to-be; Section 15.6.5 ] |
+-------+-------------------------------+-------------------------------+
| 505 | HTTP Version Not Supported | [ RFC-to-be; Section 15.6.6 ] |
+-------+-------------------------------+-------------------------------+

Fourth, a new registry called the Hypertext Transfer Protocol (HTTP) Field Name registry will be created. The new registry is to be located at

https://www.iana.org/assignments/http-fields/

All entries in the Permanent and Provisional Message Header Registries located at

https://www.iana.org/assignments/message-headers/

with the protocol 'http' are to be moved to it, with the following changes applied:

1. The 'Applicable Protocol' field is to be omitted.

2. Entries with a status of 'standard', 'experimental', 'reserved', or 'informational' are to have a status of 'permanent'.

3. Provisional entries without a status are to have a status of 'provisional'.

4. Permanent entries without a status (after confirmation that the registration document did not define one) will have a status of 'provisional'. The Expert(s) can choose to update their status if there is evidence that another is more appropriate.

The registration procedure for new registrations with permanent status is Specification Required, as defined in RFC8126. The registration procedure for new registrations with provisional status is Expert Review.

Fifth, in the Permanent and Provisional Message Header Registries at

https://www.iana.org/assignments/message-headers/

a note (with a link to the new registry) will be added to indicate that the HTTP field name registrations have moved.

Sixth, in the newly-created Hypertext Transfer Protocol (HTTP) Field Name registry at

https://www.iana.org/assignments/http-fields/

the following entries should be updated or added (and in each case the section number will be preceded by [ "RFC-to-be, Section" ]:

+===========================+============+========+============+
| Field Name | Status | Ref. | Comments |
+===========================+============+========+============+
| Accept | standard | 12.5.1 | |
+---------------------------+------------+--------+------------+
| Accept-Charset | deprecated | 12.5.2 | |
+---------------------------+------------+--------+------------+
| Accept-Encoding | standard | 12.5.3 | |
+---------------------------+------------+--------+------------+
| Accept-Language | standard | 12.5.4 | |
+---------------------------+------------+--------+------------+
| Accept-Ranges | standard | 14.3 | |
+---------------------------+------------+--------+------------+
| Allow | standard | 10.2.1 | |
+---------------------------+------------+--------+------------+
| Authentication-Info | standard | 11.6.3 | |
+---------------------------+------------+--------+------------+
| Authorization | standard | 11.6.2 | |
+---------------------------+------------+--------+------------+
| Connection | standard | 7.6.1 | |
+---------------------------+------------+--------+------------+
| Content-Encoding | standard | 8.4 | |
+---------------------------+------------+--------+------------+
| Content-Language | standard | 8.5 | |
+---------------------------+------------+--------+------------+
| Content-Length | standard | 8.6 | |
+---------------------------+------------+--------+------------+
| Content-Location | standard | 8.7 | |
+---------------------------+------------+--------+------------+
| Content-Range | standard | 14.4 | |
+---------------------------+------------+--------+------------+
| Content-Type | standard | 8.3 | |
+---------------------------+------------+--------+------------+
| Date | standard | 10.2.2 | |
+---------------------------+------------+--------+------------+
| ETag | standard | 8.8.3 | |
+---------------------------+------------+--------+------------+
| Expect | standard | 10.1.1 | |
+---------------------------+------------+--------+------------+
| From | standard | 10.1.2 | |
+---------------------------+------------+--------+------------+
| Host | standard | 7.2 | |
+---------------------------+------------+--------+------------+
| If-Match | standard | 13.1.1 | |
+---------------------------+------------+--------+------------+
| If-Modified-Since | standard | 13.1.3 | |
+---------------------------+------------+--------+------------+
| If-None-Match | standard | 13.1.2 | |
+---------------------------+------------+--------+------------+
| If-Range | standard | 13.1.5 | |
+---------------------------+------------+--------+------------+
| If-Unmodified-Since | standard | 13.1.4 | |
+---------------------------+------------+--------+------------+
| Last-Modified | standard | 8.8.2 | |
+---------------------------+------------+--------+------------+
| Location | standard | 10.2.3 | |
+---------------------------+------------+--------+------------+
| Max-Forwards | standard | 7.6.2 | |
+---------------------------+------------+--------+------------+
| Proxy-Authenticate | standard | 11.7.1 | |
+---------------------------+------------+--------+------------+
| Proxy-Authentication-Info | standard | 11.7.3 | |
+---------------------------+------------+--------+------------+
| Proxy-Authorization | standard | 11.7.2 | |
+---------------------------+------------+--------+------------+
| Range | standard | 14.2 | |
+---------------------------+------------+--------+------------+
| Referer | standard | 10.1.3 | |
+---------------------------+------------+--------+------------+
| Retry-After | standard | 10.2.4 | |
+---------------------------+------------+--------+------------+
| Server | standard | 10.2.5 | |
+---------------------------+------------+--------+------------+
| TE | standard | 10.1.4 | |
+---------------------------+------------+--------+------------+
| Trailer | standard | 10.1.5 | |
+---------------------------+------------+--------+------------+
| Upgrade | standard | 7.8 | |
+---------------------------+------------+--------+------------+
| User-Agent | standard | 10.1.6 | |
+---------------------------+------------+--------+------------+
| Vary | standard | 12.5.5 | |
+---------------------------+------------+--------+------------+
| Via | standard | 7.6.3 | |
+---------------------------+------------+--------+------------+
| WWW-Authenticate | standard | 11.6.1 | |
+---------------------------+------------+--------+------------+
| * | standard | 12.5.5 | (reserved) |
+---------------------------+------------+--------+------------+

Seventh, in the newly-created Hypertext Transfer Protocol (HTTP) Field Name registry at

https://www.iana.org/assignments/http-fields/

the entry for the "Content-MD5" item in the new registry will have its status listed as "obsoleted," with references to RFC2616, Section 14.15, and RFC7231, Appendix B.

Eighth, IANA understands that in the Hypertext Transfer Protocol (HTTP) Authentication Scheme registry located at

https://www.iana.org/assignments/http-authschemes

the current reference for the registry itself will be replaced with a reference to Section 16.4.1 of this document.

Ninth, in the HTTP Content Coding registry at

https://www.iana.org/assignments/http-parameters/

the following entries should be updated:

+============+===========================================+=========+
| Name | Description | Ref. |
+============+===========================================+=========+
| compress | UNIX "compress" data format [Welch] | 8.4.1.1 |
+------------+-------------------------------------------+---------+
| deflate | "deflate" compressed data ([RFC1951]) | 8.4.1.2 |
| | inside the "zlib" data format ([RFC1950]) | |
+------------+-------------------------------------------+---------+
| gzip | GZIP file format [RFC1952] | 8.4.1.3 |
+------------+-------------------------------------------+---------+
| identity | Reserved | 12.5.3 |
+------------+-------------------------------------------+---------+
| x-compress | Deprecated (alias for compress) | 8.4.1.1 |
+------------+-------------------------------------------+---------+
| x-gzip | Deprecated (alias for gzip) | 8.4.1.3 |
+------------+-------------------------------------------+---------+

Tenth, in the HTTP Range Unit registry at

https://www.iana.org/assignments/http-parameters/

the following entries should be updated:

+=================+==================================+========+
| Range Unit Name | Description | Ref. |
+=================+==================================+========+
| bytes | a range of octets | 14.1.2 |
+-----------------+----------------------------------+--------+
| none | reserved as keyword to indicate | 14.3 |
| | range requests are not supported | |
+-----------------+----------------------------------+--------+

Eleventh, in the media types registry at

https://www.iana.org/assignments/media-types

the existing registration for multipart/byteranges will have its current reference replaced with a reference to this document and its template information replaced with the information from Section 14.6..

Twelfth, in the Service Name and Transport Protocol Port Number registry at

https://www.iana.org/assignments/service-names-port-numbers/

the existing registrations for the ports 80 and 443 that use UDP or TCP will be modified as follows:

1. use this document as their sole reference
2. when currently unspecified, set "Assignee" to "IESG" and
"Contact" to "IETF Chair."

Thirteenth, in the Hypertext Transfer Protocol (HTTP) Upgrade Token registry at

https://www.iana.org/assignments/http-upgrade-tokens

the current reference for HTTP will be replaced with a reference to [RFC-to-be, Section 2.5].

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

NOTE: When these updates are to be made, IANA will ask the chairs and AD whether it would be appropriate to remove the word "Registry" from the names of the registries referred to above.

Thank you,

Amanda Baber
Lead IANA Services Specialist
2021-06-03
16 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2021-06-03
16 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2021-05-27
16 Jean Mahoney Request for Last Call review by GENART is assigned to Dale Worley
2021-05-27
16 Jean Mahoney Request for Last Call review by GENART is assigned to Dale Worley
2021-05-27
16 Tero Kivinen Request for Last Call review by SECDIR is assigned to Mališa Vučinić
2021-05-27
16 Tero Kivinen Request for Last Call review by SECDIR is assigned to Mališa Vučinić
2021-05-27
16 Amy Vezza Placed on agenda for telechat - 2021-06-17
2021-05-27
16 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-05-27
16 Amy Vezza
The following Last Call announcement was sent out (ends 2021-06-10):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-semantics@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com …
The following Last Call announcement was sent out (ends 2021-06-10):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-semantics@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (HTTP Semantics) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'HTTP Semantics'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Hypertext Transfer Protocol (HTTP) is a stateless application-
  level protocol for distributed, collaborative, hypertext information
  systems.  This document describes the overall architecture of HTTP,
  establishes common terminology, and defines aspects of the protocol
  that are shared by all versions.  In this definition are core
  protocol elements, extensibility mechanisms, and the "http" and
  "https" Uniform Resource Identifier (URI) schemes.

  This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
  7232
, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions
  of RFC 7230.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-semantics/



No IPR declarations have been submitted directly on this I-D.




2021-05-27
16 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-05-27
16 Francesca Palombini Last call was requested
2021-05-27
16 Francesca Palombini Last call announcement was generated
2021-05-27
16 Francesca Palombini Ballot approval text was generated
2021-05-27
16 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-05-27
16 Francesca Palombini IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-05-27
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-05-27
16 Julian Reschke New version available: draft-ietf-httpbis-semantics-16.txt
2021-05-27
16 (System) New version approved
2021-05-27
16 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-05-27
16 Julian Reschke Uploaded new revision
2021-05-26
15 (System) Changed action holders to Roy Fielding, Mark Nottingham, Julian Reschke, Francesca Palombini (IESG state changed)
2021-05-26
15 Francesca Palombini IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-04-18
15 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-04-18
15 Francesca Palombini IESG state changed to AD Evaluation from Publication Requested
2021-04-18
15 Francesca Palombini Ballot writeup was changed
2021-04-13
15 Tommy Pauly
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 

Proposed Standard; this is an update to previous standards-track documents (notably, RFC 7230). This status is indicated in the document and Datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 

Technical Summary:

This document represents a revision and consolidation of the original RFCs produced by the HTTPbis working group, which defined HTTP in various documents published in 2014. This document encapsulates the version-independent semantics of HTTP, which is now more relevant to make clear after the advent of both HTTP/2 and HTTP/3. This document is a critical reference for the work on HTTP/3 to rely upon.

Working Group Summary & Document Quality:

The working group, led by the group of three editors, has poured a lot of time and effort into ensuring that these core documents are produced with great quality and clarity. This effort to revise the documents began in 2018, and over the past three years, the working group has spent about half of its meeting time discussing the ongoing work on these core documents. A detailed list of all issues that were discussed can be found on the GitHub repo: https://github.com/httpwg/http-core/issues.

While there were certainly manly points that required in-depth discussion, through WGLC, the process was guided by consensus, which was usually not rough.

Personnel:
Document Shepherd: Tommy Pauly
Responsible Area Director: Francesca Palombini

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 

I’ve reviewed this document as part of issuing the WGLC, and followed the various comments/issues filed by the WG and discussed in our recent interim meeting. I believe this document is quite ready to be forwarded, and is a truly useful and well-written specification.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns. This document has been the product of careful and in-depth by the working group over several years, and went through a long last call.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. 

No new reviews are needed here, in my opinion. This document isn’t introducing any new behavior or architecture, but rather consolidating and clarifying existing documents.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The editors have not indicated any IPR on this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 

No IPR has been reported.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

The WG consensus seems quite solid. During WGLC, we received in-depth reviews from core participants, as well as many GitHub issues from WG participants. From when WGLC started until now, we received 54 issues on the HTTP core documents from people other than document editors.

https://github.com/httpwg/http-core/issues?q=is%3Aissue+is%3Aclosed

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 

No such complaints have been expressed.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 


-(10750): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
SHEPHERD: This is from a non-ASCII name, not a problem

  == There are 9 instances of lines with non-ascii characters in the document.

  == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.
SHEPHERD: This seems to be an incorrect nit.

  -- The draft header indicates that this document obsoletes RFC7230, but the
    abstract doesn't seem to directly say this.  It does mention RFC7230
    though, so this could be OK.

  -- The abstract seems to indicate that this document obsoletes RFC7615, but
    the header doesn't have an 'Obsoletes:' line to match this.

  -- The abstract seems to indicate that this document obsoletes RFC7538, but
    the header doesn't have an 'Obsoletes:' line to match this.

  -- The abstract seems to indicate that this document obsoletes RFC7694, but
    the header doesn't have an 'Obsoletes:' line to match this.

SHEPHERD: These are incorrect nits.

  -- The draft header indicates that this document updates RFC3864, but the
    abstract doesn't seem to mention this, which it should.

SHEPHERD: This does sound like a valid nit. https://github.com/httpwg/http-core/issues/829

  == Unused Reference: 'RFC2145' is defined on line 9325, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC7617' is defined on line 9470, but no explicit
    reference was found in the text

SHEPHERD: These looks like valid nits. https://github.com/httpwg/http-core/issues/830

  ** Downref: Normative reference to an Informational RFC: RFC 1950

  ** Downref: Normative reference to an Informational RFC: RFC 1951

  ** Downref: Normative reference to an Informational RFC: RFC 1952

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Welch'

  -- Duplicate reference: RFC2978, mentioned in 'Err5433', was also mentioned
    in 'Err1912'.

  -- Obsolete informational reference (is this intentional?): RFC 2068
    (Obsoleted by RFC 2616)

  -- Obsolete informational reference (is this intentional?): RFC 2145
    (Obsoleted by RFC 7230)

  -- Obsolete informational reference (is this intentional?): RFC 2616
    (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)

  -- Obsolete informational reference (is this intentional?): RFC 2617
    (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617)

  -- Duplicate reference: RFC2978, mentioned in 'RFC2978', was also mentioned
    in 'Err5433'.

SHEPHERD: These seem like items to clean up with AD review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 

This document updates the reference for existing media type and URI registrations, but does not create any new registrations.

(13) Have all references within this document been identified as either normative or informative? 

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 

These are highlighted by the nits checks:

  ** Downref: Normative reference to an Informational RFC: RFC 1950

  ** Downref: Normative reference to an Informational RFC: RFC 1951

  ** Downref: Normative reference to an Informational RFC: RFC 1952

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Welch'

I’ll leave these to AD guidance.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 

Please see (14) above.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 

Yes, this document changes the status of several documents, as is the intent of this major update to the core HTTP specs. These are listed and explained in the document.

Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, 7538, 7615, 7694
Updates: 3864

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 

The IANA requests for this document are primarily to move references in existing tables to point to this document, along with a few minor updates for correctness.

It does also create a new registry for HTTP Field Names, see below.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 

This document creates a new registry for HTTP Field Names. It would make sense to have this document be managed like the existing HTTP registries for expert selection, etc.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document uses ABNF rules, which have been validated.

(20) No YANG impact.
2021-04-13
15 Tommy Pauly Responsible AD changed to Francesca Palombini
2021-04-13
15 Tommy Pauly IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-04-13
15 Tommy Pauly IESG state changed to Publication Requested from I-D Exists
2021-04-13
15 Tommy Pauly IESG process started in state Publication Requested
2021-04-13
15 Tommy Pauly Tag Revised I-D Needed - Issue raised by WGLC cleared.
2021-04-02
15 Tommy Pauly
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 

Proposed Standard; this is an update to previous standards-track documents (notably, RFC 7230). This status is indicated in the document and Datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 

Technical Summary:

This document represents a revision and consolidation of the original RFCs produced by the HTTPbis working group, which defined HTTP in various documents published in 2014. This document encapsulates the version-independent semantics of HTTP, which is now more relevant to make clear after the advent of both HTTP/2 and HTTP/3. This document is a critical reference for the work on HTTP/3 to rely upon.

Working Group Summary & Document Quality:

The working group, led by the group of three editors, has poured a lot of time and effort into ensuring that these core documents are produced with great quality and clarity. This effort to revise the documents began in 2018, and over the past three years, the working group has spent about half of its meeting time discussing the ongoing work on these core documents. A detailed list of all issues that were discussed can be found on the GitHub repo: https://github.com/httpwg/http-core/issues.

While there were certainly manly points that required in-depth discussion, through WGLC, the process was guided by consensus, which was usually not rough.

Personnel:
Document Shepherd: Tommy Pauly
Responsible Area Director: Francesca Palombini

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. 

I’ve reviewed this document as part of issuing the WGLC, and followed the various comments/issues filed by the WG and discussed in our recent interim meeting. I believe this document is quite ready to be forwarded, and is a truly useful and well-written specification.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns. This document has been the product of careful and in-depth by the working group over several years, and went through a long last call.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. 

No new reviews are needed here, in my opinion. This document isn’t introducing any new behavior or architecture, but rather consolidating and clarifying existing documents.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The editors have not indicated any IPR on this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 

No IPR has been reported.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 

The WG consensus seems quite solid. During WGLC, we received in-depth reviews from core participants, as well as many GitHub issues from WG participants. From when WGLC started until now, we received 54 issues on the HTTP core documents from people other than document editors.

https://github.com/httpwg/http-core/issues?q=is%3Aissue+is%3Aclosed

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 

No such complaints have been expressed.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 


-(10750): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
SHEPHERD: This is from a non-ASCII name, not a problem

  == There are 9 instances of lines with non-ascii characters in the document.

  == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.
SHEPHERD: This seems to be an incorrect nit.

  -- The draft header indicates that this document obsoletes RFC7230, but the
    abstract doesn't seem to directly say this.  It does mention RFC7230
    though, so this could be OK.

  -- The abstract seems to indicate that this document obsoletes RFC7615, but
    the header doesn't have an 'Obsoletes:' line to match this.

  -- The abstract seems to indicate that this document obsoletes RFC7538, but
    the header doesn't have an 'Obsoletes:' line to match this.

  -- The abstract seems to indicate that this document obsoletes RFC7694, but
    the header doesn't have an 'Obsoletes:' line to match this.

SHEPHERD: These are incorrect nits.

  -- The draft header indicates that this document updates RFC3864, but the
    abstract doesn't seem to mention this, which it should.

SHEPHERD: This does sound like a valid nit. https://github.com/httpwg/http-core/issues/829

  == Unused Reference: 'RFC2145' is defined on line 9325, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC7617' is defined on line 9470, but no explicit
    reference was found in the text

SHEPHERD: These looks like valid nits. https://github.com/httpwg/http-core/issues/830

  ** Downref: Normative reference to an Informational RFC: RFC 1950

  ** Downref: Normative reference to an Informational RFC: RFC 1951

  ** Downref: Normative reference to an Informational RFC: RFC 1952

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Welch'

  -- Duplicate reference: RFC2978, mentioned in 'Err5433', was also mentioned
    in 'Err1912'.

  -- Obsolete informational reference (is this intentional?): RFC 2068
    (Obsoleted by RFC 2616)

  -- Obsolete informational reference (is this intentional?): RFC 2145
    (Obsoleted by RFC 7230)

  -- Obsolete informational reference (is this intentional?): RFC 2616
    (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)

  -- Obsolete informational reference (is this intentional?): RFC 2617
    (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617)

  -- Duplicate reference: RFC2978, mentioned in 'RFC2978', was also mentioned
    in 'Err5433'.

SHEPHERD: These seem like items to clean up with AD review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 

This document updates the reference for existing media type and URI registrations, but does not create any new registrations.

(13) Have all references within this document been identified as either normative or informative? 

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? 

These are highlighted by the nits checks:

  ** Downref: Normative reference to an Informational RFC: RFC 1950

  ** Downref: Normative reference to an Informational RFC: RFC 1951

  ** Downref: Normative reference to an Informational RFC: RFC 1952

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Welch'

I’ll leave these to AD guidance.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. 

Please see (14) above.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. 

Yes, this document changes the status of several documents, as is the intent of this major update to the core HTTP specs. These are listed and explained in the document.

Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, 7538, 7615, 7694
Updates: 3864

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). 

The IANA requests for this document are primarily to move references in existing tables to point to this document, along with a few minor updates for correctness.

It does also create a new registry for HTTP Field Names, see below.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. 

This document creates a new registry for HTTP Field Names. It would make sense to have this document be managed like the existing HTTP registries for expert selection, etc.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document uses ABNF rules, which have been validated.

(20) No YANG impact.
2021-04-02
15 Tommy Pauly Notification list changed to tpauly@apple.com because the document shepherd was set
2021-04-02
15 Tommy Pauly Document shepherd changed to Tommy Pauly
2021-04-02
15 Tommy Pauly Changed consensus to Yes from Unknown
2021-04-02
15 Tommy Pauly Intended Status changed to Proposed Standard from None
2021-03-30
15 Julian Reschke New version available: draft-ietf-httpbis-semantics-15.txt
2021-03-30
15 (System) New version approved
2021-03-30
15 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-03-30
15 Julian Reschke Uploaded new revision
2021-02-12
14 Tommy Pauly Tag Revised I-D Needed - Issue raised by WGLC set.
2021-02-12
14 Tommy Pauly IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-01-14
14 Tommy Pauly IETF WG state changed to In WG Last Call from WG Document
2021-01-12
14 Julian Reschke New version available: draft-ietf-httpbis-semantics-14.txt
2021-01-12
14 (System) New version approved
2021-01-12
14 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-01-12
14 Julian Reschke Uploaded new revision
2020-12-14
13 Julian Reschke New version available: draft-ietf-httpbis-semantics-13.txt
2020-12-14
13 (System) New version approved
2020-12-14
13 (System) Request for posting confirmation emailed to previous authors: Mark Nottingham , Roy Fielding , Julian Reschke
2020-12-14
13 Julian Reschke Uploaded new revision
2020-10-02
12 Julian Reschke New version available: draft-ietf-httpbis-semantics-12.txt
2020-10-02
12 (System) New version approved
2020-10-02
12 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Mark Nottingham , Julian Reschke
2020-10-02
12 Julian Reschke Uploaded new revision
2020-08-27
11 Julian Reschke New version available: draft-ietf-httpbis-semantics-11.txt
2020-08-27
11 (System) New version approved
2020-08-27
11 (System) Request for posting confirmation emailed to previous authors: Mark Nottingham , Julian Reschke , Roy Fielding
2020-08-27
11 Julian Reschke Uploaded new revision
2020-07-12
10 Julian Reschke New version available: draft-ietf-httpbis-semantics-10.txt
2020-07-12
10 (System) New version approved
2020-07-12
10 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Roy Fielding , Mark Nottingham
2020-07-12
10 Julian Reschke Uploaded new revision
2020-07-11
09 Julian Reschke New version available: draft-ietf-httpbis-semantics-09.txt
2020-07-11
09 (System) New version approved
2020-07-11
09 (System) Request for posting confirmation emailed to previous authors: Mark Nottingham , Julian Reschke , Roy Fielding
2020-07-11
09 Julian Reschke Uploaded new revision
2020-05-26
08 Julian Reschke New version available: draft-ietf-httpbis-semantics-08.txt
2020-05-26
08 (System) New version approved
2020-05-26
08 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2020-05-26
08 Julian Reschke Uploaded new revision
2020-03-07
07 Julian Reschke New version available: draft-ietf-httpbis-semantics-07.txt
2020-03-07
07 (System) New version approved
2020-03-07
07 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Roy Fielding , Mark Nottingham
2020-03-07
07 Julian Reschke Uploaded new revision
2019-11-04
06 Julian Reschke New version available: draft-ietf-httpbis-semantics-06.txt
2019-11-04
06 (System) New version approved
2019-11-04
06 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2019-11-04
06 Julian Reschke Uploaded new revision
2019-07-08
05 Julian Reschke New version available: draft-ietf-httpbis-semantics-05.txt
2019-07-08
05 (System) New version approved
2019-07-08
05 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2019-07-08
05 Julian Reschke Uploaded new revision
2019-04-30
04 Mark Nottingham This document now replaces draft-fielding-httpbis-http-semantics, draft-nottingham-httpbis-header-registry, draft-ietf-httpbis-auth, draft-ietf-httpbis-conditional, draft-ietf-httpbis-range instead of draft-fielding-httpbis-http-semantics, draft-ietf-httpbis-auth, draft-ietf-httpbis-conditional, draft-ietf-httpbis-range
2019-03-09
04 Julian Reschke New version available: draft-ietf-httpbis-semantics-04.txt
2019-03-09
04 (System) New version approved
2019-03-09
04 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2019-03-09
04 Julian Reschke Uploaded new revision
2018-10-18
03 Julian Reschke New version available: draft-ietf-httpbis-semantics-03.txt
2018-10-18
03 (System) New version approved
2018-10-18
03 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2018-10-18
03 Julian Reschke Uploaded new revision
2018-07-02
02 Julian Reschke New version available: draft-ietf-httpbis-semantics-02.txt
2018-07-02
02 (System) New version approved
2018-07-02
02 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2018-07-02
02 Julian Reschke Uploaded new revision
2018-05-31
01 Mark Nottingham This document now replaces draft-fielding-httpbis-http-semantics, draft-ietf-httpbis-auth, draft-ietf-httpbis-conditional, draft-ietf-httpbis-range instead of draft-fielding-httpbis-http-semantics
2018-05-31
01 Julian Reschke New version available: draft-ietf-httpbis-semantics-01.txt
2018-05-31
01 (System) New version approved
2018-05-31
01 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2018-05-31
01 Julian Reschke Uploaded new revision
2018-05-30
00 Mark Nottingham This document now replaces draft-fielding-httpbis-http-semantics instead of None
2018-04-03
00 Julian Reschke New version available: draft-ietf-httpbis-semantics-00.txt
2018-04-03
00 (System) WG -00 approved
2018-04-03
00 Julian Reschke Set submitter to ""Julian F. Reschke" ", replaces to (none) and sent approval email to group chairs: httpbis-chairs@ietf.org
2018-04-03
00 Julian Reschke Uploaded new revision