- From: Jeffrey Yasskin <jyasskin@google.com>
- Date: Sun, 25 Mar 2018 00:48:38 +0000
- To: rfc-editor@rfc-editor.org
- Cc: fielding@gbiv.com, julian.reschke@greenbytes.de, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, Mark Nottingham <mnot@mnot.net>, pmcmanus@mozilla.com, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CANh-dXmGDtrKWjShrJ4CR7AsQAcT3Fe0zOJ4DsBUwNpLfSg2EA@mail.gmail.com>
It probably makes sense to handle this during the HTTPtre process. I filed an erratum to be sure not to forget it between now and when that repository is created. Jeffrey On Sat, Mar 24, 2018 at 7:01 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC7231, > "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5300 > > -------------------------------------- > Type: Technical > Reported by: Jeffrey Yasskin <jyasskin@google.com> > > Section: 8.1 > > Original Text > ------------- > 8.1.1. Procedure > > HTTP method registrations MUST include the following fields: > > o Method Name (see Section 4) > > o Safe ("yes" or "no", see Section 4.2.1) > > o Idempotent ("yes" or "no", see Section 4.2.2) > > o Pointer to specification text > > Values to be added to this namespace require IETF Review (see > [RFC5226], Section 4.1). > > … > > 8.1.3. Registrations > > The "Hypertext Transfer Protocol (HTTP) Method Registry" has been > populated with the registrations below: > > +---------+------+------------+---------------+ > | Method | Safe | Idempotent | Reference | > +---------+------+------------+---------------+ > | CONNECT | no | no | Section 4.3.6 | > | DELETE | no | yes | Section 4.3.5 | > | GET | yes | yes | Section 4.3.1 | > | HEAD | yes | yes | Section 4.3.2 | > | OPTIONS | yes | yes | Section 4.3.7 | > | POST | no | no | Section 4.3.3 | > | PUT | no | yes | Section 4.3.4 | > | TRACE | yes | yes | Section 4.3.8 | > +---------+------+------------+---------------+ > > Corrected Text > -------------- > 8.1.1. Procedure > > HTTP method registrations MUST include the following fields: > > o Method Name (see Section 4) > > o Safe ("yes" or "no", see Section 4.2.1) > > o Idempotent ("yes" or "no", see Section 4.2.2) > > o Cacheable ("yes" or "no", see Section 4.2.3) > > o Pointer to specification text > > Values to be added to this namespace require IETF Review (see > [RFC5226], Section 4.1). > > … > > 8.1.3. Registrations > > The "Hypertext Transfer Protocol (HTTP) Method Registry" has been > populated with the registrations below: > > +---------+------+------------+-----------+---------------+ > | Method | Safe | Idempotent | Cacheable | Reference | > +---------+------+------------+-----------+---------------+ > | CONNECT | no | no | no | Section 4.3.6 | > | DELETE | no | yes | no | Section 4.3.5 | > | GET | yes | yes | yes | Section 4.3.1 | > | HEAD | yes | yes | yes | Section 4.3.2 | > | OPTIONS | yes | yes | no | Section 4.3.7 | > | POST | no | no | yes | Section 4.3.3 | > | PUT | no | yes | no | Section 4.3.4 | > | TRACE | yes | yes | no | Section 4.3.8 | > +---------+------+------------+-----------+---------------+ > > Notes > ----- > HTTP Methods have 3 boolean properties, all of which 8.1.2 says a > registration needs to define, but only 2 of them were included in the > registry. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7231 (draft-ietf-httpbis-p2-semantics-26) > -------------------------------------- > Title : Hypertext Transfer Protocol (HTTP/1.1): Semantics > and Content > Publication Date : June 2014 > Author(s) : R. Fielding, Ed., J. Reschke, Ed. > Category : PROPOSED STANDARD > Source : Hypertext Transfer Protocol Bis APP > Area : Applications > Stream : IETF > Verifying Party : IESG >
Received on Sunday, 25 March 2018 00:49:17 UTC