[Web-SIG] a possible error in the WSGI spec
Manlio Perillo
It seems that there is a little error in the WSGI spec.
In the "Specification Details" chapter there is this note:
"""(Note: the application must invoke the start_response() callable
before the iterable yields its first body string, so that the server can
send the headers before any body content. However, this invocation may
be performed by the iterable's first iteration, so servers must not
assume that start_response() has been called before they begin iterating
over the iterable.)"""
What's wrong is that the invocation of start_response may be performed
at any iteration of the iterable, as long as the application yields
empty strings.
There is also a little problem in the "The start_response() Callable"
chapter, in this phrase:
"""The start_response callable must not actually transmit the response
headers. Instead, it must store them for the server or gateway to
transmit only after the first iteration of the application return value
that yields a non-empty string, or upon the application's first
invocation of the write() callable"""
From this it seems that the response headers should be transmitted
after the first invocation of the write() callable, even if it returns
an empty string, but this is in contradiction with the following phrase:
"""In other words, response headers must not be sent until there is
actual body data available, or until the application's returned iterable
is exhausted"""
Manlio Perillo
_______________________________________________
Web-SIG mailing list
Web...@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/python-web-sig-garchive-9074%40googlegroups.com
Adam Atlas
On 20 Dec 2007, at 07:27, Manlio Perillo wrote:
> What's wrong is that the invocation of start_response may be performed
> at any iteration of the iterable, as long as the application yields
> empty strings.
In what context? I suspect that's an error in a particular
implementation, not in the spec.
Phillip J. Eby
>Hi.
>
>It seems that there is a little error in the WSGI spec.
>
>In the "Specification Details" chapter there is this note:
>
>"""(Note: the application must invoke the start_response() callable
>before the iterable yields its first body string, so that the server can
>send the headers before any body content. However, this invocation may
>be performed by the iterable's first iteration, so servers must not
>assume that start_response() has been called before they begin iterating
>over the iterable.)"""
>
>
>What's wrong is that the invocation of start_response may be performed
>at any iteration of the iterable, as long as the application yields
>empty strings.
You're right - the intent here was before the iterable yields its
first non-empty body string.
>There is also a little problem in the "The start_response() Callable"
>chapter, in this phrase:
>
>"""The start_response callable must not actually transmit the response
>headers. Instead, it must store them for the server or gateway to
>transmit only after the first iteration of the application return value
>that yields a non-empty string, or upon the application's first
>invocation of the write() callable"""
>
>
> From this it seems that the response headers should be transmitted
>after the first invocation of the write() callable, even if it returns
>an empty string, but this is in contradiction with the following phrase:
>
>"""In other words, response headers must not be sent until there is
>actual body data available, or until the application's returned iterable
>is exhausted"""
There is no sane reason to call write() with an empty string, so I
don't really see a conflict here.
Please note that both write() and iteration in the normal case should
be sending the entire response body in a single call or
yield. Multiple yields or write() calls should ONLY be used when
streaming output is *required*: i.e. server push or sending large files.
(In addition, write() is intended strictly for legacy apps and
frameworks only; new code should use iteration only, especially as
WSGI 2 will drop the start_response() and write() functions altogether.)
Manlio Perillo
> [...]
>> There is also a little problem in the "The start_response() Callable"
>> chapter, in this phrase:
>>
>> """The start_response callable must not actually transmit the response
>> headers. Instead, it must store them for the server or gateway to
>> transmit only after the first iteration of the application return value
>> that yields a non-empty string, or upon the application's first
>> invocation of the write() callable"""
>>
>>
>> From this it seems that the response headers should be transmitted
>> after the first invocation of the write() callable, even if it returns
>> an empty string, but this is in contradiction with the following phrase:
>>
>> """In other words, response headers must not be sent until there is
>> actual body data available, or until the application's returned iterable
>> is exhausted"""
>
> There is no sane reason to call write() with an empty string, so I don't
> really see a conflict here.
>
Yes, there are no sane reasons, but it is still not explicitly forbidden.
> Please note that both write() and iteration in the normal case should be
> sending the entire response body in a single call or yield. Multiple
> yields or write() calls should ONLY be used when streaming output is
> *required*: i.e. server push or sending large files.
>
> (In addition, write() is intended strictly for legacy apps and
> frameworks only; new code should use iteration only, especially as WSGI
> 2 will drop the start_response() and write() functions altogether.)
>
>
By the way: isn't it better to first release a WSGI 1.1 before jumping
to a (incompatible) WSGI 2.0?
Manlio Perillo
Phillip J. Eby
>By the way: isn't it better to first release a WSGI 1.1 before
>jumping to a (incompatible) WSGI 2.0?
Better for whom, and for what purpose?
Graham Dumpleton
> At 12:28 PM 12/24/2007 +0100, Manlio Perillo wrote:
> >By the way: isn't it better to first release a WSGI 1.1 before
> >jumping to a (incompatible) WSGI 2.0?
>
> Better for whom, and for what purpose?
As has been pointed out before, the main discrepancy known of is the
definition of readline() on wsgi.input. Don't know of anything that
implements it per the specification because if it was written per the
specification then cgi.FieldStorage wouldn't work.
The other more recent issue is how to interpret the WSGI specification
for Python 3.
Personally I don't think it is sufficient that the only mention of
these issues is in the archives of the mailing list. Even if you
personally don't want a version 1.1 specification, would you consider
an official addendum to the 1.0 specification with it being at least
posted on www.wsgi.org if the PEP itself can't be amended.
Graham
Phillip J. Eby
>On 26/12/2007, Phillip J. Eby <p...@telecommunity.com> wrote:
> > At 12:28 PM 12/24/2007 +0100, Manlio Perillo wrote:
> > >By the way: isn't it better to first release a WSGI 1.1 before
> > >jumping to a (incompatible) WSGI 2.0?
> >
> > Better for whom, and for what purpose?
>
>As has been pointed out before, the main discrepancy known of is the
>definition of readline() on wsgi.input. Don't know of anything that
>implements it per the specification because if it was written per the
>specification then cgi.FieldStorage wouldn't work.
>
>The other more recent issue is how to interpret the WSGI specification
>for Python 3.
>
>Personally I don't think it is sufficient that the only mention of
>these issues is in the archives of the mailing list. Even if you
>personally don't want a version 1.1 specification, would you consider
>an official addendum to the 1.0 specification with it being at least
>posted on www.wsgi.org if the PEP itself can't be amended.
These are good things to have, sure. But this doesn't answer the
question of why doing that first would be *better* than doing 2.0
first, assuming that there is any reason why they can't or shouldn't
be worked on concurrently.
Graham Dumpleton
> At 04:15 PM 12/26/2007 +1100, Graham Dumpleton wrote:
> >On 26/12/2007, Phillip J. Eby <p...@telecommunity.com> wrote:
> > > At 12:28 PM 12/24/2007 +0100, Manlio Perillo wrote:
> > > >By the way: isn't it better to first release a WSGI 1.1 before
> > > >jumping to a (incompatible) WSGI 2.0?
> > >
> > > Better for whom, and for what purpose?
> >
> >As has been pointed out before, the main discrepancy known of is the
> >definition of readline() on wsgi.input. Don't know of anything that
> >implements it per the specification because if it was written per the
> >specification then cgi.FieldStorage wouldn't work.
> >
> >The other more recent issue is how to interpret the WSGI specification
> >for Python 3.
> >
> >Personally I don't think it is sufficient that the only mention of
> >these issues is in the archives of the mailing list. Even if you
> >personally don't want a version 1.1 specification, would you consider
> >an official addendum to the 1.0 specification with it being at least
> >posted on www.wsgi.org if the PEP itself can't be amended.
>
> These are good things to have, sure. But this doesn't answer the
> question of why doing that first would be *better* than doing 2.0
> first, assuming that there is any reason why they can't or shouldn't
> be worked on concurrently.
Because your name is on the WSGI PEP, people tend to look to you to
take a lead on things rather than cross you and do it in your absence.
The WSGI 2.0 specification has been brought up before on a number of
occasions and although a number of discussion points have been brought
up, it is effectively dead in the water and nothing is happening. If
you were to take the ideas for WSGI 2.0 on board and push forward with
it as most seem to be expecting, then maybe jumping to 2.0 could
happen, but it isn't.
Due to this inactivity at least, some I guess would like to see the
1.1 specification created or at least an amendment to 1.0 to at least
adjust points in the original specification that were in hindsight
wrong or impractical, plus allow for Python 3.0. It is a silly
situation to have that many if not all WSGI adapters in existence are
not even strictly in compliance with the specification.
If there is never going to be a 1.1, then maybe we should start a
campaign to force all developers of WSGI adapters to modify their code
to make it 1.0 compliant. If that then means that most of the Python
web frameworks then no longer work, then so be it, after all, they
can't be WSGI compliant either if that is the case.
Now, if you feel that you aren't really the BDFL for the WSGI
specification then clearly state that and let us get on with setting
up a proper community process, including some form of voting and
oversight mechanism to herald the development of the WSGI 2.0.
Otherwise I can't really see much happening with it as it appears that
everyone is waiting for you to carry it forward from here.
Graham
Phillip J. Eby
>Due to this inactivity at least, some I guess would like to see the
>1.1 specification created or at least an amendment to 1.0 to at least
>adjust points in the original specification that were in hindsight
>wrong or impractical, plus allow for Python 3.0. It is a silly
>situation to have that many if not all WSGI adapters in existence are
>not even strictly in compliance with the specification.
I'd love it if somebody would be so kind as to distill a summary of
the points that need to go into a 1.0 errata/clarifications document,
and I would be happy to update the PEP (and perhaps make it Final, at
long last) following discussion and consensus where possible,
pronouncement where not.
I don't think a 1.1 is *necessarily* required; most of the issues
that might make a 1.1 desirable may be better handled via a 2.0, and
getting some closure on the issues that *can* be closed for 1.0 could
be a good place to start that process.
>Otherwise I can't really see much happening with it as it appears that
>everyone is waiting for you to carry it forward from here.
I've been thinking, actually, that the best way to get the WSGI 2.0
ball rolling would be to write some code. Given that 2.0 is intended
to make writing apps and middleware simpler, it would make more sense
for its design to be driven by somewhat more aesthetic
considerations. Also, we have the ability now to take any of the
large body of WSGI 1.0 code and see what it would look like under
2.0, so we can be less theoretical as well.
At the same time though, finishing 1.0 will be a good start to
2.0. I want it to be utterly trivial for a 2.0 app to run under a
1.0 server, and *possible* to run 1.0 apps under a 2.0 server, with
some potential restrictions. (A 1.0 app that uses write() calls
would require either buffering -- which technically violates the 1.0
spec -- or threading, or greenlets, in order to run under 2.0.)
So, having the hairy bits of 1.0 fully nailed down, and having a list
of what bits we know cause trouble and would like to change, would be
good to know before trying to create a formal spec.
Informally, OTOH, playing with 2.0 prototypes should be pretty
informative, too.
Manlio Perillo
>> On 26/12/2007, Phillip J. Eby <p...@telecommunity.com> wrote:
>> > At 12:28 PM 12/24/2007 +0100, Manlio Perillo wrote:
>> > >By the way: isn't it better to first release a WSGI 1.1 before
>> > >jumping to a (incompatible) WSGI 2.0?
>> >
>> > Better for whom, and for what purpose?
>>
>
>
> These are good things to have, sure. But this doesn't answer the
> question of why doing that first would be *better* than doing 2.0 first,
> assuming that there is any reason why they can't or shouldn't be worked
> on concurrently.
>
The problem is that WSGI 2.0 does not yet exists; instead WSGI 1.0 has
already been implemented in several different environments so it seems
better to first "complete" WSGI 1.0 (errata, addendum, or 1.1).
Manlio Perillo
Manlio Perillo
> [...]
>
> informative, too.
>
In my WSGI implementation for Nginx I started with the 2.0 draft, since
the code flow is more simpler.
However, now that I have implemented 1.0, it's a bit hard to add support
for 2.0.
Moreover I'm not very interested in 2.0 now, since I want first
experiment with the asynchronous extension for 1.0 (pause_output) to see
if something good can be done with it.
Manlio Perillo
Graham Dumpleton
> >Due to this inactivity at least, some I guess would like to see the
> >1.1 specification created or at least an amendment to 1.0 to at least
> >adjust points in the original specification that were in hindsight
> >wrong or impractical, plus allow for Python 3.0. It is a silly
> >situation to have that many if not all WSGI adapters in existence are
> >not even strictly in compliance with the specification.
>
> I'd love it if somebody would be so kind as to distill a summary of
> the points that need to go into a 1.0 errata/clarifications document,
> and I would be happy to update the PEP (and perhaps make it Final, at
> long last) following discussion and consensus where possible,
> pronouncement where not.
>
> I don't think a 1.1 is *necessarily* required; most of the issues
> that might make a 1.1 desirable may be better handled via a 2.0, and
> getting some closure on the issues that *can* be closed for 1.0 could
> be a good place to start that process.
I have created the page:
http://www.wsgi.org/wsgi/Amendments_1.0
I added the obvious candidates.
Anyone else who has ever taken issue with the 1.0 specification,
please add any other things which you think would be reasonable.
Include links to mailing list archives where issue may have previously
been discussed.
Thanks.
Graham
Manlio Perillo
> [...]
>
> I have created the page:
>
> http://www.wsgi.org/wsgi/Amendments_1.0
>
> I added the obvious candidates.
>
Thanks.
> Anyone else who has ever taken issue with the 1.0 specification,
> please add any other things which you think would be reasonable.
> Include links to mailing list archives where issue may have previously
> been discussed.
>
Only one note: isn't it better to add links to the "official" archives
of the mailing list:
http://mail.python.org/pipermail/web-sig/
instead of using google groups?
> Thanks.
>
> Graham
>
Manlio Perillo
Graham Dumpleton
> Graham Dumpleton ha scritto:
> > Anyone else who has ever taken issue with the 1.0 specification,
> > please add any other things which you think would be reasonable.
> > Include links to mailing list archives where issue may have previously
> > been discussed.
>
> Only one note: isn't it better to add links to the "official" archives
> of the mailing list:
> http://mail.python.org/pipermail/web-sig/
> instead of using google groups?
Personally I'd say Google Groups is better as it is easier for some
one not subscribed to the web-sig list to add to the linked
conversation without having to subscribe to the actual list.
Graham