root/asynwsgi/trunk/transfer-encoding.rst

Revision 331, 1.8 kB (checked in by robin, 2 years ago)

merge: 0.2-1-r314-branch-wsgicompat => trunk r330

* Huge chunk of new stuff in chunkcodingapi all pertaining to Transfer-Encoding: chunked; as defined in rfc2616. It is all completely independent of socketapi. Which makes it usefull for stand alone testing. Particularly pleased with the implementation of encode_chunks_tosocket. Particularly *displeased* with the corroralry, yieldchunks_fromsocket. decodechunks_tofile is bearable (just)
* bench client gained the ability to spawn of a server with --profile enabled, and then kill it once the -n requests have completed. This is usefull for
comparing results between change sets.
.
The branch was intended to fully address wsgi compat but it did not. I'm not
happy with the interface for iterabl wsgi.input. The input implenentation
now has two modes: iterable read, biased heavily towards consumption of
chunk encoded uploads, and a readline compatible version that pulls all
chunks into memory before starting the application.
.
I'm going to branch again specifically with view to makeing a nicer & more
performant iterable input. It will make no attempt to provide wsgi compatible
readline. It MAY implement an iterable input instance. we shall see.
.
Tests pass and this commit is a reasonably usefull point for a tag. So this
is gouing to become 0.3 shortly
.
There are some additional profile results, for both simple the "Hello World"
app and the file upload stuff.

wsgi.input for Transfer-Encoding: chunked;

environ['wsgi.input'] is set to an instance of this class when the following conditions are met:

  1. The user agent is speaking HTTP/1.1
  2. The request specifies Transport-Encoding: chunked;

see: http://mail.python.org/pipermail/web-sig/2004-September/000879.html

Thinking out loud: 1. & 2. can not occur independently, Transfer-Encoding: chunked; is HTTP/1.1 only.

What would an asynwsgi aware app look like ?

if 'Transfer-Encoding' in environ:
if TE_NOT_SUPPORTED_BY_THIS_APP:
environ['CONNECTION']='close' ??? non-standard but easy start_response(, some_error)
for chunk in environ['wsgi.input']:

# v is on of ['', environ['wsgi.input'], response_chunk] # it it is the input instance the application has completely # consumed the current chunk and must not be resumed until # the next chunk is available. # # if its the empty string its a co-operative yield # otherwise v must be transmited fully to the client before # resuming the application. v = response = start_chunk(environ, chunk) yield v for v in response:

System Message: ERROR/3 (<string>, line 33)

Unexpected indentation.
yield v

Keep-Alive vs close ?

This implementation assumes that either:

  1. The application will iterate over its input OR
  2. The application will use read or readlines to consume its input.

And that the application will do on of two things when there is no CONTENT_LENGTH in the environ:

System Message: ERROR/3 (<string>, line 44)

Unexpected indentation.
  1. call input.read() with no parameters OR
  2. synthesize an error and set the Connection:close header.

Strictly speaking pep-333 does not allow b) as it means the application/ middle ware is setting a hop-by-hop header. This server will allways honour an application or middle wares request for connection:close.

Note: See TracBrowser for help on using the browser.