[Web-SIG] Draft PEP: WSGI 1.1

[Manlio Perillo]

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