def pauseProducing(self):
        """
        Pause producing data.

        This will be called by the transport when the send buffers have been
        filled up. We want to simultaneously pause the producing L{Request}
        object and also pause our transport.

        The logic behind pausing the transport is specifically to avoid issues
        like https://twistedmatrix.com/trac/ticket/8868. In this case, our
        inability to send does not prevent us handling more requests, which
        means we increasingly queue up more responses in our send buffer
        without end. The easiest way to handle this is to ensure that if we are
        unable to send our responses, we will not read further data from the
        connection until the client pulls some data out. This is a bit of a
        blunt instrument, but it's ok.

        Note that this potentially interacts with timeout handling in a
        positive way. Once the transport is paused the client may run into a
        timeout which will cause us to tear the connection down. That's a good
        thing!
        """
        self._waitingForTransport = True

        # The first step is to tell any producer we might currently have
        # registered to stop producing. If we can slow our applications down
        # we should.
        if self._requestProducer is not None:
            self._requestProducer.pauseProducing()

        # The next step here is to pause our own transport, as discussed in the
        # docstring.
        if not self._handlingRequest:
            self._networkProducer.pauseProducing()

        Pause producing data.

        This will be called by the transport when the send buffers have been
        filled up. We want to simultaneously pause the producing L{Request}
        object and also pause our transport.

        The logic behind pausing the transport is specifically to avoid issues
        like https://twistedmatrix.com/trac/ticket/8868. In this case, our
        inability to send does not prevent us handling more requests, which
        means we increasingly queue up more responses in our send buffer
        without end. The easiest way to handle this is to ensure that if we are
        unable to send our responses, we will not read further data from the
        connection until the client pulls some data out. This is a bit of a
        blunt instrument, but it's ok.

        Note that this potentially interacts with timeout handling in a
        positive way. Once the transport is paused the client may run into a
        timeout which will cause us to tear the connection down. That's a good
        thing!
        
stackoverflow/venv/lib/python3.6/site-packages/twisted/web/http.py