Unfortunately, I think we have to reject this report. Though the values for these entries might be useless, we can't change this without creating interoperability issues.
On Fri, Dec 16, 2022, at 10:31, RFC Errata System wrote: > The following errata report has been submitted for RFC9204, > "QPACK: Field Compression for HTTP/3". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7277 > > -------------------------------------- > Type: Technical > Reported by: Rory Hewitt <rory.hew...@gmail.com> > > Section: Appendix A > > Original Text > ------------- > In the static table, entry 73 has a value of: > > access-control-allow-credentials: TRUE > > and entry 74 has a value of: > > access-control-allow-credentials: FALSE > > Corrected Text > -------------- > Entry 73 should have a value of: > > access-control-allow-credentials: true > > (note the lower-case value of "true") > > and entry 74 should NOT EXIST since "FALSE" (in upper-case > or lower-case) is not a valid value for this header. > > Notes > ----- > The "access-control-allow-credentials" header is a CORS header. It only > has one allowed value - "true" (without quotes, MUST be in lower-case). > Values of "TRUE", "FALSE" and "false" are all invalid values, as is any > mixed-case version of "true". > > See the latest WHATWG spec at > https://fetch.spec.whatwg.org/#cors-protocol-and-credentials which > notes the required case-sensitivity of the "true" value and that it is > the only valid value. > > Also see the prior W3C spec at > https://www.w3.org/TR/2020/SPSD-cors-20200602/#access-control-allow-credentials-response-header > > which says the same thing. Note that the W3C spec was superseded by the > WHATWG spec. > > Note that there are many instances of > "access-control-allow-credentials: false" being returned from server > responses (which is presumably why these values were added to the > table), but they are invalid and the servers that send them are not > following the CORS specification. > > There may be case to be made that the static table is defined to make > the QPACK algorithm as performant as possible and therefore it should > include not only commonly-used valid values, but also commonly-used > invalid values. However, the static table should ideally contain only > valid header values. > > 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. > > -------------------------------------- > RFC9204 (draft-ietf-quic-qpack-21) > -------------------------------------- > Title : QPACK: Field Compression for HTTP/3 > Publication Date : June 2022 > Author(s) : C. Krasic, M. Bishop, A. Frindell, Ed. > Category : PROPOSED STANDARD > Source : QUIC > Area : Transport > Stream : IETF > Verifying Party : IESG
