RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (2)

RFC 2388, "Returning Values from Forms: multipart/form-data", August 1998

Note: This RFC has been obsoleted by RFC 7578

Source of RFC: Legacy
Area Assignment: app

Errata ID: 4030
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Anne van Kesteren
Date Reported: 2014-06-30
Verifier Name: Barry Leiba
Date Verified: 2014-07-01

Section Appendix A says: 

Required parameters:
  none

It should say:

Required parameters:
  boundary (see Section 4.1)

Notes:

Without that parameter you cannot parse the payload body.

Errata ID: 2937
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anne van Kesteren
Date Reported: 2011-08-14
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 5.6 says: 

application/x-url-encoded

It should say:

application/x-www-form-urlencoded

Notes:

This incorrect media type appears twice and should be replaced both times. In the last paragraph of this section "both" and "as well" can be removed.

Status: Held for Document Update (2)

RFC 2388, "Returning Values from Forms: multipart/form-data", August 1998

Note: This RFC has been obsoleted by RFC 7578

Source of RFC: Legacy
Area Assignment: app

Errata ID: 2011
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Julian Reschke
Date Reported: 2010-01-21
Held for Document Update by: Peter Saint-Andre

Section boilerplate says: 

Network Working Group                                         L. Masinter
Request for Comments: 2388                              Xerox Corporation
Category: Standards Track                                     August 1998

It should say:

Network Working Group                                         L. Masinter
Request for Comments: 2388                              Xerox Corporation
Updates: 1867                                                 August 1998
Category: Standards Track

Notes:

RFC 2388 updated the definition of multipart/form-data, which was previously defined in RFC 1867. It appears the RFC Index should reflect that.

Errata ID: 5410
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sébastien Puyet
Date Reported: 2018-06-26
Held for Document Update by: Alexey Melnikov
Date Held: 2018-07-26

Section 4.1 says: 

   As with other multipart types, a boundary is selected that does not
   occur in any of the data. Each field of the form is sent, in the
   order defined by the sending appliction and form, as a part of the
   multipart stream.  Each part identifies the INPUT name within the
   original form. Each part should be labelled with an appropriate
   content-type if the media type is known (e.g., inferred from the file
   extension or operating system typing information) or as
   "application/octet-stream".

It should say:

   As with other multipart types, a boundary is selected that does not
   occur in any of the data. Each field of the form is sent, in the
   order defined by the sending application and form, as a part of the
   multipart stream.  Each part identifies the INPUT name within the
   original form. Each part should be labelled with an appropriate
   content-type if the media type is known (e.g., inferred from the file
   extension or operating system typing information) or as
   "application/octet-stream".

Notes:

A typo is present in the second sentence, the word "appliction" should be "application".

Alexey: why this is correct, this is unlikely to get readers confused. So marking it as "held for document update".

Report New Errata



Advanced Search