twisted.web.http.HTTPChannel(basic.LineReceiver, policies.TimeoutMixin) class documentation

Called when a connection is made.

This may be considered the initializer of the protocol, because it is called when the connection is completed. For clients, this is called once the connection to the server has been established; for servers, this is called after an accept() call stops blocking and a socket has been received. If you need to send any greeting or initial message, do it here.

Called for each line from request until the end of headers when it enters binary mode.

Do pre-processing (for content-length) and store this header away. Enforce the per-request header limit.

Override this for when raw data is received.

Check if the channel should close or not.

Called by first request in queue when it is done.

Called when the connection times out.

Override to define behavior other than dropping the connection.

Called if abortTimeout seconds have passed since the timeout fired, and the connection still hasn't gone away. This can really only happen on extremely bad connections or when clients are maliciously attempting to keep connections open.

Called when the connection is shut down.

Clear any circular references here, and any external references to this Protocol. The connection has been closed.

Return True if this channel is using a secure transport.

Normally this method returns True if this instance is using a transport that implements interfaces.ISSLTransport.

Called by Request objects to write a complete set of HTTP headers to a transport.

Called by Request objects to write response data.

Write a list of strings to the HTTP response.

Get the remote address of this connection.

Get the local address of this connection.

Closes the connection. Will write any data that is pending to be sent on the network, but if this response has not yet been written to the network will not write anything.

Register to receive data from a producer.

This sets self to be a consumer for a producer. When this object runs out of data (as when a send(2) call on a socket succeeds in moving the last data from a userspace buffer into a kernelspace buffer), it will ask the producer to resumeProducing().

For IPullProducer providers, resumeProducing will be called once each time data is required.

For IPushProducer providers, pauseProducing will be called whenever the write buffer fills up and resumeProducing will only be called when it empties.

Stop consuming data from a producer, without disconnecting.

Stop producing data.

The HTTPChannel doesn't *actually* implement this, beacuse the assumption is that it will only be called just before loseConnection is called. There's nothing sensible we can do other than call loseConnection anyway.

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 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!

Resume producing data.

This will be called by the transport when the send buffer has dropped enough to actually send more data. When this happens we can unpause any outstanding Request producers we have, and also unpause our transport.