Hi Lucas, This to me sounds like “Hold for doc update”, not necessarily to do design changes but just to clarify these points. Would you agree?
Francesca > Hey, > > Arguably from a QPACK perspective, these entries are not useless, since > they can be used by a server that wants to encode a header field with that > name and value. QPACK doesn't have an opinion on header syntax, as long as > the entries in its table meet its own rules things are ok. That can > sometimes surprise people, something higher up the stack has to deal with > validating fields themselves. For a HTTP proxy, if it were passing through > "access-control-allow-credentials: TRUE" it's likely to be doing so > verbatim, and so QPACK offers the chance to do it using a smaller encoding. > > It's also worth noting that QPACK encoding can use an indexed field name > without needing to use the value, for instance using the indexed field name > (entry 73 or 74) and a string literal "true". And given the length of the > string "access-control-allow-credentials" there are still compression > savings to be had from using its index instead. Or an implementation could > try to match "access-control-allow-credentials: true" to a static table, > fail and just insert it into their dynamic table without batting an eyelid. > > The background to the choice of QPACK static table entries is probably > sumamrised best on > https://github.com/quicwg/base-drafts/wiki/QPACK-Static-Table. > > I agree it's unfortunate that we captured some information in the table > that turned out not to be compliant with its related specification. Any > design change to support alternative static tables is going to be hard and > disruptive. A note to say the entry values are non-standard might help. > However, we'd want to understand who the target audience is and whether > they'd really care about what we said. > > Cheers > Lucas > > On Fri, Dec 16, 2022 at 10:07 AM Magnus Westerlund <magnus.westerlund= > [email protected]<mailto:[email protected]>> wrote: > > > Hi, > > > > > > > > Isn’t this a Hold for Update case? The table is wrong in the sense that it > > contains useless entries as they don’t represent syntactically correct > > values. And in the future if the static table is revised and a way of > > knowing that the peer uses the revised table this should be addressed. So I > > would think a Hold for Update is an appropriate response to this errata. Or > > even just to clarify in the spec that these are mostly useless. > > > > > > > > Cheers > > > > > > > > Magnus Westerlund > > > > > > > > *From: *QUIC [email protected]<mailto:[email protected]> on behalf > > of Martin Thomson < > > [email protected]<mailto:[email protected]>> > > *Date: *Friday, 16 December 2022 at 01:31 > > *To: *[email protected]<mailto:*[email protected]> > > [email protected]<mailto:[email protected]> > > *Subject: *Re: [Technical Errata Reported] RFC9204 (7277) > > > > 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 > > > [email protected]<mailto:[email protected]> > > > > > > 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 > > >
