| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Recently we have updated our receive window size to a larger value.
Unfortunately, this also results in auto-test pumping through
more data, which probably takes more time on CI.
At the moment we do not have any public API on QNAM's level to
customize HTTP/2 parameters (aka 5.10/FF and so on). So we use the fact
that QNAM is QObject and we can set a property on it. This property
is our Http2::ProtocolParameters object that allows us to configure:
- HPACK parameters (in 5.10 - noop)
- session receive window size
- different SETTINGS as described by RFC 7540, 6.5.2.
2. Undocumented environment variable to set ENABLE_PUSH is not needed
anymore.
3. In 5.11 Http2::ProtocolParameter will become a public API
and we'll introduce a new setter in QNAM.
Change-Id: If08fd5e09e7c0b61cf9700b426b60b5837b6b2e6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using the default ones, provided by RFC7540. It appears they are way
too restrictive and conservative: when downloading something relatively big,
a stream keeps spending the whole session/its own 'recv' windows and thus
we have to constantly send WINDOW_UPDATE frames. This significantly slows
down our HTTP/2 implementation, making it orders of magnitude slower than
HTTP/1.1. To fix this:
- We send SETTINGS_INITIAL_WINDOW_SIZE in the first SETTINGS frame
to inform our peer that per-stream WINDOW is bigger than 64Kb
- We increase the session's receive window size.
Task-number: QTBUG-63722
Change-Id: I31312fcfd5f0fc0aee6aaa5d3562cc7d1b931adc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without TLS (and thus ALPN/NPN negotiation) HTTP/2 requires
a protocol upgrade procedure, as described in RFC 7540, 3.2.
We start as HTTP/1.1 (and thus we create QHttpProtocolHandler first),
augmenting the headers we send with 'Upgrade: h2c'. In case
we receive HTTP/1.1 response with status code 101 ('Switching
Protocols'), we continue as HTTP/2 session, creating QHttp2ProtocolHandler
and pretending the first request we sent was HTTP/2 request
on a real HTTP/2 stream. If the first response is something different
from 101, we continue as HTTP/1.1. This change also required
auto-test update: our toy-server now has to respond to
the initial HTTP/1.1 request on a platform without ALPN/NPN.
As a bonus a subtle flakyness in 'goaway' auto-test went
away (well, it was fixed).
[ChangeLog][QtNetwork][HTTP/2] In case of clear text HTTP/2 we
now initiate a required protocol upgrade procedure instead of
'H2Direct' connection.
Task-number: QTBUG-61397
Change-Id: I573fa304fdaf661490159037dc47775d97c8ea5b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
HTTP/2 allows a server to pre-emptively send (or "push") responses (along
with corresponding "promised" requests) to a client in association with a
previous client-initiated request. This can be useful when the server
knows the client will need to have those responses available in order
to fully process the response to the original request.
Server push is semantically equivalent to a server responding to a request;
however, in this case, that request is also sent by the server, as a
PUSH_PROMISE frame.
The PUSH_PROMISE frame includes a header block that contains a complete set
of request header fields that the server attributes to the request.
After sending the PUSH_PROMISE frame, the server can begin delivering the
pushed response as a response on a server-initiated stream that uses the
promised stream identifier.
This patch:
- fixes the HPACK decompression of PUSH_PROMISE frames;
- allows a user to enable PUSH_PROMISE;
- processes and caches pushed data for promised streams;
- updates auto-test - emulates a simple PUSH_PROMISE
scenario.
Change-Id: Ic4850863a5e3895320baac3871a723fc091b4aca
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce new entity: class Http2::Frame with accessors like
payloadSize/type/flags/streamID etc. (they actually read
/interpret raw bytes from a frame's buffer) instead of
duplicating this functionality in reader/writer classes.
Delete defaulted members and remove explicitly defined
move ctors/operators (not needed actually).
Update auto-test ('HTTP/2 server') to use these new classes.
Change-Id: Ie3516efbd095704e212142eef9e792323678ccfa
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
|
|
|
|
|
|
|
| |
Setting END_HEADERS flag on a HEADERS frame means we do not have
CONTINUATION frame(s). So do NOT set it too early, only if we
fit into a single frame.
Change-Id: I891a2db227cee59e4eacfe7c2f18b431cd85fe47
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Whenever we have a read notification, read this data, even if it's not
enough for a frame's header - otherwise, QNAM can use a socket
in an Ubuffered mode and FrameReader can potentially fail to read
anything correctly.
- Do not call/rely on bytesAvailable and do not try to invoke
_q_receiveReply in Qt::QueuedConnection mode, instead try to read
until we end up in an incomplete frame or some error.
Change-Id: I7f44ba9e34bc64f3e26bd29080f0050da635b3ae
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 12d71f4ea20415ff2274e1e90f9e4d5a8b935d7f.
This change is breaking a build + incomplete as my test revealed.
Will have to re-try later.
Change-Id: I7ea089093a832aa5822caaaac56e62f5fda4df17
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without ALPN/NPN (== without OpenSSL) we can negotiate HTTP/2
using the protocol upgrade procedure as described by RFC7540.
Since there is no TLS handshake, after our http channel was connected
we first send an 'augmented' HTTP/1.1 request - its header
contains additional 'HTTP2-Settings' and 'Upgrade' (to 'h2c') fields.
If we receive reponse 101 (switch protocol) we re-create a protocol
handler and switch to HTTP/2.
Task-number: QTBUG-50955
Change-Id: I36e9985e06ba76edaf7fdb22bb43770f8d593c61
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
|
|
|
|
|
|
|
| |
Found while implementing cleartext http2 (and sending some erroneous
frames) - GOAWAY can have some 'opaque debug information payload' so the
frame's size is at least 8 bytes, but can be more.
Change-Id: I90fb8a3df22768673c4f40ba3bf6a3f5ffe33058
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
QtNetwork: qtbase/src/network/access/http2/http2frames_p.h does not have the "We mean it." warning
QtNetwork: qtbase/src/network/access/http2/http2protocol_p.h does not have the "We mean it." warning
QtNetwork: qtbase/src/network/access/http2/http2streams_p.h does not have the "We mean it." warning
Amends change b2c0f9713c1c39bc3214df49f0d2b44bcc84d790.
Task-number: QTBUG-50956
Change-Id: Ia266a4f8625d89745b3a2dcaff6b15a712e9cadc
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
| |
Add HTTP2 support in QNAM - QHttp2ProtocolHandler + aux. classes.
[ChangeLog][QtNetwork] Added support for HTTP/2 protocol
Task-number: QTBUG-50956
Change-Id: I3a119cfbb1fb3118d9003225f5e54b46ae2829b6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
Static Huffman coding + HPACK encode/decode algorithm (for HTTP2)
+ auto test.
Change-Id: I85d6269076cc1d586d17c87bcdee49c21522ef78
Task-number: QTBUG-50946
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
