Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Newer
Older
100644 122 lines (90 sloc) 4.57 kb
e17f68c8 »
2011-08-19 Initial page structure.
1 Proposals related to WSGI 2.0
2 =============================
59fcfdab »
2011-08-26 Initial port of the WSGI2 page to RST
3
4 This page is intended to collect any ideas related to WSGI 2.0. In
5 particular, any proposed changes to the specification.
6
7dd02052 »
2011-08-26 Use a note directive for the note block at te top of the WSGI2 page
7 .. note:: What is described here should not be considered a DRAFT for
8 WSGI 2.0. It is only a list of ideas or issues that need to be
9 considered if there ever is enough momentum towards producing an
10 updated WSGI specification. It is quite possible that there may
11 never be an updated specification which embodies the ideas described
12 here. Thus, if you implement any web application interfaces based on
13 the API described here, call it something else, do not call it WSGI
14 2.0 as no such thing exists.
59fcfdab »
2011-08-26 Initial port of the WSGI2 page to RST
15
16 start_response and write
17 ------------------------
18
19 We could remove start_response and the writer that it implies. This
20 would lead to a signature like:
21
22 .. code-block:: python
23
24 def app(environ):
25 return '200 OK', [('Content-type', 'text/plain')], ['Hello world']
26
27 That is, return a three-tuple of ``(status, headers, app_iter)``.
28
29 It's relatively simple to provide adapters to and from this signature
30 to the WSGI 1.0 signature.
31
32 Making some keys required
33 -------------------------
34
35 Several keys are optional in WSGI, but required in CGI, in particular
70a7c4d3 »
2011-08-26 Use Sphinx roles to markup envvars and Python classes in WSGI2 document
36 :envvar:`SCRIPT_NAME`, :envvar:`PATH_INFO` and
37 :envvar:`QUERY_STRING`. Also :envvar:`REMOTE_ADDR` and
38 :envvar:`SERVER_SOFTWARE` are supposed to exist, even if empty. All
39 these keys could become required in WSGI.
59fcfdab »
2011-08-26 Initial port of the WSGI2 page to RST
40
41 Unknown-length wsgi.input
42 -------------------------
43
44 There's no documented way to indicate that there is content in
45 ``environ['wsgi.input']``, but the content length is unknown. A value
70a7c4d3 »
2011-08-26 Use Sphinx roles to markup envvars and Python classes in WSGI2 document
46 of ``-1`` may work in many situations. A missing
47 :envvar:`CONTENT_LENGTH` doesn't generally work currently (it's
48 assumed to mean 0 by much code).
59fcfdab »
2011-08-26 Initial port of the WSGI2 page to RST
49
50 This is an issue because chunked transfer encoding on request content
51 can't be supported properly unless there is a way to indicate that
52 there is data with unknown content length. Also an issue with a web
53 server or WSGI middleware component that mutates the input stream
54 (eg. decompression), where it will not know the new content length in
55 advance of mutating the data stream.
56
57 Any change in this area also needs to take into consideration the
58 current link between CGI and WSGI specifications and whether the CGI
59 requirement to not read more input data than defined by
70a7c4d3 »
2011-08-26 Use Sphinx roles to markup envvars and Python classes in WSGI2 document
60 :envvar:`CONTENT_LENGTH` and that returning an EOF indicator is
61 optional is really appropriate for WSGI.
59fcfdab »
2011-08-26 Initial port of the WSGI2 page to RST
62
63 For more information see thread:
64 http://mail.python.org/pipermail/web-sig/2007-March/002630.html
65
66 readline(size)
67 --------------
68
69 Currently the specification does not require servers to provide
70 ``environ['wsgi.input'].readline(size)`` (the size argument in
70a7c4d3 »
2011-08-26 Use Sphinx roles to markup envvars and Python classes in WSGI2 document
71 particular). But :py:class:`cgi.FieldStorage` calls readline this way,
72 so in effect it is required.
59fcfdab »
2011-08-26 Initial port of the WSGI2 page to RST
73
74 app_iter and threads
75 --------------------
76
77 It's not clear if the app_iter must be used in the same thread as the
78 application. Since the application is blocking, presumably it must be
79 run all in one thread. This should be more explicitly documented.
80
81 long response headers
82 ---------------------
83
84 Noted here:
85 http://mail.python.org/pipermail/web-sig/2006-September/002244.html
86
87 request trailers and chunked transfer encoding
88 ----------------------------------------------
89
90 When using chunked transfer encoding on request content, the RFCs
91 allow there to be request trailers. These are like request headers but
92 come after the final null data chunk. These trailers are only
93 available when the chunked data stream is finite length and when it
94 has all been read in, thus not available at time that start
95 application is called.
96
97 Decoding SCRIPT_NAME/PATH_INFO
98 ------------------------------
99
70a7c4d3 »
2011-08-26 Use Sphinx roles to markup envvars and Python classes in WSGI2 document
100 Because :envvar:`SCRIPT_NAME` and :envvar:`PATH_INFO` are decoded in
101 WSGI, there's no way to distinguish ``%2F`` from ``/``
59fcfdab »
2011-08-26 Initial port of the WSGI2 page to RST
102
103 No encoding horrors any more
104 ----------------------------
105
106 Analysis see there:
107 http://www.mail-archive.com/web-sig@python.org/msg02483.html
108
109 Can we have that horror removed for wsgi2 apps, please?
110
111 A quite easy approach would be to have a set of ``RAW_*`` env vars
70a7c4d3 »
2011-08-26 Use Sphinx roles to markup envvars and Python classes in WSGI2 document
112 (e.g. :envvar:`RAW_PATH_INFO`) that has ``/Foo%XXBar%YY`` content (is
113 not decoded, plain ascii like in the http protocol).
59fcfdab »
2011-08-26 Initial port of the WSGI2 page to RST
114
115 That also would solve issues with ``?`` and ``/`` (see section above)
116 that are encoded as ``%XX`` (and NOT meant as query / path component
117 separator).
118
119 Any wsgi1 app can continue to use the wsgi1 env vars, any wsgi2 app
120 can check whether the wsgi2 ``RAW_*`` env vars are there and use them
121 (or fall back to using the wsgi1 env vars).
Something went wrong with that request. Please try again.