Re: [Technical Errata Reported] RFC9204 (7277)

[Lucas Pardue <[e-mail]>]

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