Re: [Technical Errata Reported] RFC9204 (7277)

(+ 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.
>
> >
>
> > 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
>
> > > >
>
> > > > --------------------------------------
>
> > > > 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 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
>
> > >
>
> >
>