On 05/05/17 12:10, Cory Benfield wrote:
As a second note, you may lock yourself out of HTTP/2. HTTP/2 is not guaranteed to give you access to a raw transport object (though it
FWIW this kind of thing was, more or less, what I was thinking. It seems unlikely that stealing the TCP connection from Response for a few bytes was wise...
As a third note, your code does not handle the possibility that original._transport may not implement IPushProducer. While *in
IIUC IResponse.deliverBody *does* guarantee (currently) to provide a transport implementing IPushProducer to the supplied IProtocol, at least as far as the docstring says?
Obviously that doesn't make accessing the private _transport safe - an implementation could wrap the transport to implement the IPushProducer semantics.
practice* it tends to, it needn’t. On top of that, it is not forbidden for an IPushProducer implementation to call write() even when paused, and code that wants to be correct in the face of all situations will need to be able to buffer anyway.
Thanks for confirming this. I suspected as much, but was not certain (I make relatively little use of producer/consumer APIs in my own code).
use case. Right now it’s a bit of an annoyance that t.w._newclient doesn’t allow the body receiving protocol to exert backpressure on the data.
How does that square with deliverBody providing an IPushProducer? Is it the case that the transport may just disobey the pauseProducing requests as you've noted above?
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
