All, Now that the HTTP/2 server changes have landed, one of the things I’d like to start dealing with is server Resource dispatch. Those of you who have been paying attention to this mailing list will remember that we discussed this a bit back when I was originally implementing HTTP/2 logic, and we ended up deferring the work for a while. It’s time to re-discuss this.
To try to avoid boiling the ocean I’d like to divide this into small steps. Adi
has pointed out Twisted ticket #6928, which includes an original patch to allow
Resources to opt-in to early-dispatch when headers are received. This allows
them to handle 100 Continue more feature fully than Twisted does today (where
it unconditionally emits 100 Continue). If Adi is up for it, I’m willing to
take over the lead reviewer role for that patch and try to help shepherd it
through the process.
The rest of this mail is a commentary on the proposed interface, which you can
see here[0]. Note that the patch available there is non-functional: we’re
mostly concerned with discussing the interfaces, more than we’re concerned
about the actual function of the patch.
Ok, let’s go.
Adi, my high level summary is that this patch looks reasonable. headersReceived
is a sensible interface, and while I don’t like the names
IEarlyHeaders{Request,Resource}, those names can be addressed later in the
review process. An obvious thing missing from your draft is that the
HTTPChannel doesn’t check for IEarlyHeadersRequest before calling
headersReceived, but that’s presumably an oversight.
I’d like separate patches that implement IEarlyHeadersResource for some
relevant built-in resources, such as t.w.static.File, mostly so we can confirm
that the behaviour works in cases where we do not need to check the request
content.
Otherwise, I think this is a good enough prototype to start working from. The
biggest question mark I have is how we plan to evolve this. The next logical
step, presumably, is a new set of interfaces (children of
IEarlyHeaders{Request,Resource}) that allow for streaming body delivery. I’m a
bit nervous about wanting to publish too many of these *intermediary*
interfaces, especially because it will mean we need fallback code for each case
(what about Resources that don’t implement IEarlyHeadersResource?, what about
Resources that don’t implement IStreamingBodyResource? each requires a new code
path). In this instance, I’d want to be pretty aggressive about deprecating
older interfaces and ensuring that people move to the newer interface model.
Perhaps when we merge this we should deprecate plain Resource objects and
encourage people to move to IEarlyHeadersResource, so that they have a smaller
delta when streaming resources are implemented too.
Those are my high level thoughts. If anyone else has feedback please feel free
to leap in, but otherwise I’m going to encourage Adi to provide a “proper”
patch (or possibly sequence of patches) that we can more formally review.
Cory
[0]:
https://github.com/twisted/twisted/compare/trunk...chevah:6928-http-100-accept
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
