- From: Rory Hewitt <rory.hewitt@gmail.com>
- Date: Mon, 29 Jan 2024 09:22:11 -0800
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAEmMwDyijeog7nSLak=LyOLsgw2_7XZPbvob+DmcGik5A0sENQ@mail.gmail.com>
I raised this errata, and FWIW, I'm also happy with a hold. I specifically mentioned this scenario in Section3 of my https://www.ietf.org/archive/id/draft-hewitt-ietf-qpack-static-table-version-02.html I-D, but that hasn't gained any traction... Thanks, Rory (+ HTTP WG) I could live with a hold, and people can use this erratum to decide the scope of work if QPACK is ever revved. Cheers Lucas On Mon, Jan 29, 2024 at 9:16 AM Francesca Palombini < francesca.palombini@ericsson.com> wrote: 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 <https://urldefense.com/v3/__https:/github.com/quicwg/base-drafts/wiki/QPACK-Static-Table__;!!GjvTz_vk!WoSjF4WVpyhW3CB_oCuI_cxbLu6QuUgxzXD6JH-LF7zq2cF2gX7mptY-uque59DUD0BgMjnBlz__qJrStEEuDnQA$> . > > 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= > 40ericsson.com@dmarc.ietf.org> 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 quic-bounces@ietf.org on behalf of Martin Thomson < > > mt@lowentropy.net> > > *Date: *Friday, 16 December 2022 at 01:31 > > *To: *quic@ietf.org quic@ietf.org > > *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 <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid7277__;!!GjvTz_vk!WoSjF4WVpyhW3CB_oCuI_cxbLu6QuUgxzXD6JH-LF7zq2cF2gX7mptY-uque59DUD0BgMjnBlz__qJrStKKiy1JP$> > > > > > > -------------------------------------- > > > Type: Technical > > > Reported by: Rory Hewitt rory.hewitt@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 <https://urldefense.com/v3/__https:/fetch.spec.whatwg.org/*cors-protocol-and-credentials__;Iw!!GjvTz_vk!WoSjF4WVpyhW3CB_oCuI_cxbLu6QuUgxzXD6JH-LF7zq2cF2gX7mptY-uque59DUD0BgMjnBlz__qJrStIkeWUzo$> 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 <https://urldefense.com/v3/__https:/www.w3.org/TR/2020/SPSD-cors-20200602/*access-control-allow-credentials-response-header__;Iw!!GjvTz_vk!WoSjF4WVpyhW3CB_oCuI_cxbLu6QuUgxzXD6JH-LF7zq2cF2gX7mptY-uque59DUD0BgMjnBlz__qJrStJYd4Xja$> > > > 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 > > > -- Rory Hewitt https://www.linkedin.com/in/roryhewitt
Received on Monday, 29 January 2024 17:22:51 UTC