Re: [Technical Errata Reported] RFC9204 (7277)

[Francesca Palombini <[e-mail]>]

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=
> [e-mail]<mailto:[e-mail]>> 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 [e-mail]<mailto:[e-mail]> on behalf of Martin Thomson <
> > [e-mail]<mailto:[e-mail]>>
> > *Date: *Friday, 16 December 2022 at 01:31
> > *To: *[e-mail]<mailto:*[e-mail]> [e-mail]<mailto:[e-mail]>
> > *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 [e-mail]<mailto:[e-mail]>
> > >
> > > 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
> >
>