Dirkjan Ochtman ha scritto: > [...] > --- pep-0333.txt 2010-04-15 14:46:02.000000000 +0200 > +++ wsgi-1.1.txt 2010-04-15 14:51:39.000000000 +0200 > @@ -1,114 +1,124 @@ > [...]
> Abstract > ======== > > [...] > -Thus, simplicity of implementation on *both* the server and framework > -sides of the interface is absolutely critical to the utility of the > -WSGI interface, and is therefore the principal criterion for any > -design decisions. > - > -Note, however, that simplicity of implementation for a framework > -author is not the same thing as ease of use for a web application > -author. WSGI presents an absolutely "no frills" interface to the > -framework author, because bells and whistles like response objects and > -cookie handling would just get in the way of existing frameworks' > -handling of these issues. Again, the goal of WSGI is to facilitate > -easy interconnection of existing servers and applications or > -frameworks, not to create a new web framework. > - This, and the rest of the abstract, should not entirely be removed, IMHO. > [...] > - > -Finally, it should be mentioned that the current version of WSGI > -does not prescribe any particular mechanism for "deploying" an > -application for use with a web server or server gateway. At the > -present time, this is necessarily implementation-defined by the > -server or gateway. After a sufficient number of servers and > -frameworks have implemented WSGI to provide field experience with > -varying deployment requirements, it may make sense to create > -another PEP, describing a deployment standard for WSGI servers and > -application frameworks. This should not be removed. > [...] > + > +Differences with WSGI 1.0 > +========================= > + > +Descriptive changes > +------------------- > + > +The following changes were made to realign the spec with > +implementations 'in the wild'. > + This text feels wrong, to me, > +1. The 'readline()' function of 'wsgi.input' must optionally take > + a size hint. This is required because many applications use > + cgi.FieldStorage, which uses this functionality. > + What values are supported for size? Are values -1 and None supported? > [...] > +3. Any WSGI application or middleware should not itself return, or > + consume from a wrapped WSGI component This is not very clear. What is the meaning of "consume from a wrapped WSGI component"? > , more data than specified by > + the Content-Length response header if defined. Middleware that > + does this is arguably broken and can generate incorrect data. > + This is just a clarification of obligations. > + > [...] > + > +String handling changes > +----------------------- > + > +The following changes were made to make WSGI work on Python 3.x. > + > +1. The application is passed an instance of a Python dictionary > + containing what is referred to as the WSGI environment. All keys > + in this dictionary are native strings. For CGI variables, all names > + are going to be ISO-8859-1 "going to be ISO-8859-1" should be expressed in more precise terms. Moreover, you should probably define first what a "native string" is, or you shoudl add a note that it is defined later in the document. > and so where native strings are > + unicode strings, that encoding is used for the names of CGI > + variables. > + > +2. For the WSGI variable 'wsgi.url_scheme' contained in the WSGI > + environment, the value of the variable should be a native string. > + > +3. For the CGI variables contained in the WSGI environment, the values > + of the variables are native strings. Where native strings are > + unicode strings, ISO-8859-1 encoding would be used such that the What is the precise meaning of *would*, here? > + original character data is preserved and as necessary the unicode > + string can be converted back to bytes and thence decoded to unicode > + again using a different encoding. > + > +4. The WSGI input stream 'wsgi.input' contained in the WSGI environment > + and from which request content is read, should yield byte strings. > + "yield" should be replaced with "return". And, again, why are you using *should*, here? Is an implementation allowed to return a native string? See my previous comment for "native string", about the use od "byte string" here. > [...] > @@ -575,13 +602,14 @@ > ===================== =============================================== > Variable Value > ===================== =============================================== > -``wsgi.version`` The tuple ``(1,0)``, representing WSGI > +``wsgi.version`` The tuple ``(1, 0)``, representing WSGI > version 1.0. > Should be (1, 1), not (1, 0). > [...] > > -Proposed/Under Discussion > -========================= > - I see no real reasons for removing this section. > [...] Moreover, should the section "Supporting Older (<2.2) Versions of Python" be removed? > - > Acknowledgements > ================ > Since WSGI 1.1 contains only corrections for WSGI 1.0, I see no reasons to remove original contributors to WSGI 1.0. > [...] Regards Manlio _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com