We need to, following the RFC, send a Dynamic Table Size Update using
HPack once we have acknowledged the setting as long as the new size is
smaller, or if we decide to use the new, larger size.
It's further complicated by the fact that we need to send this update on
the next 'field block' (anything with headers in it), and we may have
multiple SETTING frames come in, and we need to then acknowledge the
_smallest_ one as well as the _final_ one. This is so the decoder on the
peer's side can know that we have set the smallest size, and trimmed our
tables thusly, before going to the larger size.
This could, for example, be used to clear the table.
Task-number: QTBUG-132277
Change-Id: I2b886e125f2c197bc3d42aa0b2bbd308ed2a687c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 57f44d6d882e09f1560f86816fac6ca8d06264fc)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 55dc2af21db3059600465b194daf08cacd925e05)
Is needed when sending more SETTINGS frames during the test later
Task-number: QTBUG-132277
Change-Id: I24b2a5d1b2e7aecd8687db5b24f37233df3b91dd
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 6e7a15f5c50a94216bcf35241ec008e6c419ba18)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit b91edac40d4ca62c19038853f0e45d48b0957325)
RFC 9913 differentiates between stream errors and connection errors.
Some error handling only requires stream errors in the form of
RST_STREAM frames, while other sever errors require connection errors
in the from of GOAWAY frames.
This patch streamlines the sending of RST_STREAM frames, and ensures
that they are sent whenever mandated by RFC 9113. In some cases this
was missing, in some cases we were sending connection errors instead
of stream errors.
Further this patch adds tests to ensure the correct behavior.
Fixes: QTBUG-122345
Pick-to: 6.7
Change-Id: Ic93ae7a358a4eb551aa23342a6683cdd5dd0abb0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit d17d260948e16549d82f1fdd4dec98d246b0622e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It was overlooked in testing, but it would emit a signal for new
incoming stream even if the server was just replying with HEADERS on a
stream the client had initiated. Or vice-versa.
Pick-to: 6.7
Change-Id: Ie7b3a45729a78106da1d8c058e15705cc7dcc53b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
For use in QtGRPC.
There is some duplication between this code and the code in
QHttp2ProtocolHandler. But let's not change the implementation of
the protocol handler after the 6.7 beta release. Nor do I think we
should do it for 6.8 LTS. So let's just live with the duplication
until that has branched.
Pick-to: 6.7
Fixes: QTBUG-105491
Change-Id: I69aa38a3c341347e702f9c07c27287aee38a16f2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Mårten Nordheim
Lena Biliaieva
Matthias Rauter
Lucie Gérard