Permalink
Newer
Older
100644 122 lines (90 sloc) 4.46 KB
1
Proposals related to WSGI 2.0
2
=============================
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
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.
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
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.
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
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).
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
60
:envvar:`CONTENT_LENGTH` and that returning an EOF indicator is
61
optional is really appropriate for WSGI.
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
71
particular). But :py:class:`cgi.FieldStorage` calls readline this way,
72
so in effect it is required.
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
100
Because :envvar:`SCRIPT_NAME` and :envvar:`PATH_INFO` are decoded in
101
WSGI, there's no way to distinguish ``%2F`` from ``/``
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
112
(e.g. :envvar:`RAW_PATH_INFO`) that has ``/Foo%XXBar%YY`` content (is
113
not decoded, plain ascii like in the http protocol).
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).