[Twisted-Python] Improvements to Resource dispatch

[Cory Benfield]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://twistedmatrix.com/pipermail/twisted-python/attachments/20160621/40b446b8/attachment.pgp>