[Twisted-Python] Streaming Requests

Mark Williams markrwilliams at gmail.com
Sun Jan 8 17:50:55 MST 2017


On Sun, Jan 08, 2017 at 07:34:53PM -0500, Jean-Paul Calderone wrote:
> Hi Mark,
>
> Thanks for tackling this long-standing issue!
>

I hope I actually make some progress :)

> >   He also noted that the Request interface with which HTTPChannel
> >   interacts is mostly not described by twisted.iweb.IRequest.  That
> >   means we can augment the ways HTTPChannel talks to Request-like
> >   things without breaking many public APIs.
> >
> >
> How will this affect applications which have implemented Request-alike
> classes (for example, for testing purposes)?  The interface may not be
> explicitly defined as a Zope Interface right now but it is defined by the
> current implementation and it is largely public (ie, non-_-prefixed
> names).  Tests may have hooked in to parts of Request not documented by
> IRequest out of necessity.  It would be a shame to break such carefully
> crafted automated tests.
>

The new streaming request interface will define how HTTPChannel talks
to a completely separate Request-like implementation.  HTTPChannel can
then inspect what interface is provided by the object returned from
its requestFactory and either use the existing code path or the new
streaming one.  The default requestFactory will remain
twisted.web.http.Request.

These things taken together should mean that existing code doesn't
need to change at all.  I hope to use Twisted's own tests to verify
this, but I might use Flocker's as well.

I'd like to point out that this approach means that defining
_IDeprecatedHTTPChannelToRequestInterface isn't strictly necessary.
I'd like to do so anyway to help me track the existing API so I'm less
likely to break it, and to make the dispatch logic in HTTPChannel more
robust.




More information about the Twisted-Python mailing list