Closed GallaFrancesco closed 6 years ago
The HPACK sources still need a vibe.http.internal.http.
prefix in their module names and imports.
Of course, sorry I got a bit caught up. Should be done, I'll commit the changes for the rest of frame.d
tomorrow.
I added the missing parts of frame.d
which are mainly two methos, one for building frames (buildHTTP2Frame
) and the other to parse them (unpackHTTP2Frame
). All the methods in the module are nogc
compatible.
I decided to include these changes too so that the frame.d
module should be complete, for now. The functions buildHTTP2Frame
and unpackHTTP2Frame
, along with the ones useful to create headers, are meant to be the access points to the module, so that a possible HTTP2RequestHandler
can use them to retrieve the payload of each frame and manage it according to the frame type.
To complete the module I still have to finish the unittest for unpackHTTP2Frame
, they should be done by tomorrow.
Anything still missing from your side? Otherwise I'd pull the trigger and merge.
No, I'd say it's all here. I've almost completed a first draft for Streams, I'll submit a PR so that we can discuss that. Thanks!
The proposed changes to
vibe-http
are the following:vibe-http/source/vibe/http/internal/http2
vibe-http/source/vibe/http/internal/http2/hpack
frame.d
module has been added, containing the implementation of astruct HTTP2FrameHeader
which can be accessed through 3 utility functions (createHTTP2FrameHeader
,serializeHTTP2FrameHeader
,unpackHTTP2FrameHeader
). This module is fullynogc
compatible and can be used to serialize / deserialize an HTTP/2 Frame Header. The next PR will contain the implementation of specific frame types (all of them are defined in RFC 7540). This, once completed, should allow for serialization and deserialization of frame headers and frame payloads, after which we could move on to stream implementation.