Ian, know you have seen this before, but didn't realise you hadn't
cc'd the list. I have added a new response to part 4 of what you
originally sent that wasn't in first reply that went direct to you.
2009/8/4 Ian Bicking :
> On Mon, Aug 3, 2009 at 7:38 PM, Graham
> D
2009/8/5 P.J. Eby :
> So what, precisely, are you proposing should happen when such bytes are
> present?
Treat me as a business manager who has read just enough IT magazines
to be dangerous. As I have said before in prior discussions, my area
is C coding and trying to implement a Python hosting so
2009/8/11 James Y Knight :
> On Aug 10, 2009, at 10:11 PM, James Bennett wrote:
>>
>> Earlier today I posted an article on my blog following up on some
>> discussions of WSGI
>
> I find it a bit odd that you again claim WSGI doesn't support chunked
> transfers after that was thoroughly explained he
2009/8/12 Henry Precheur :
> Using bytes for all `environ` values is easy to understand on the
> application side as long as you are aware of the encoding problem. The
> cost is inconvenience, but that's probably OK. It's also simpler to
> implement on the gateway/server side.
Use of bytes everywh
2009/8/12 Ian Bicking :
> On Tue, Aug 11, 2009 at 6:25 PM, Graham Dumpleton
> wrote:
>>
>> 2009/8/12 Henry Precheur :
>> > Using bytes for all `environ` values is easy to understand on the
>> > application side as long as you are aware of the encoding problem.
2009/8/12 Henry Precheur :
> On Wed, Aug 12, 2009 at 09:25:21AM +1000, Graham Dumpleton wrote:
>> Use of bytes everywhere can be inconvenient on the gateway/server
>> side, at least as far as end result for user.
>
> Yes, but wouldn't it be simpler for mod_wsgi to only de
2009/8/12 Ian Bicking :
> On Tue, Aug 11, 2009 at 11:19 PM, Robert Brewer wrote:
>>
>> > 5. When running under Python 3, servers MUST provide CGI HTTP and
>> > server variables as strings. Where such values are sourced from a byte
>> > string, be that a Python byte string or C string, they should
2009/8/12 Ian Bicking :
> On Tue, Aug 11, 2009 at 11:19 PM, Robert Brewer wrote:
>>
>> > 5. When running under Python 3, servers MUST provide CGI HTTP and
>> > server variables as strings. Where such values are sourced from a byte
>> > string, be that a Python byte string or C string, they should
2009/9/18 Armin Ronacher :
> Hi,
>
> Graham mentioned that the WSGI development might further drift apart
> based on the changes Ian Bicking and I did on DjangoCon in a separate hg
> repository [1] for the WSGI PEP.
>
> I just want to point out that these are in no way final and are further
> inten
2009/9/18 Armin Ronacher :
> Hi,
>
> This is my first reply in a list of replies for Grahams lengthy blog
> post about WSGI 3 [1]. I break it up into multiple separate threads so
> that this can be discussed easier.
>
>> What should be highlighted is that for Jython, as I understand it at
>> least
2009/9/18 Armin Ronacher :
> Hi,
>
> Graham currently proposes[1] the following behaviors for Strings in WSGI
> (Python version independent). However this mail only covers the Python
> 3 part which I assume becomes a separate section in the PEP or even WSGI
> version.
>
> Terminology:
>
> byte st
2009/9/18 René Dudfield :
> On Fri, Sep 18, 2009 at 8:56 AM, Graham Dumpleton
> wrote:
>>> The big problems are always PATH_INFO and SCRIPT_NAME. Those are the
>>> only values that are in the dict URL-decoded and might contain non-ASCII
>>> characters. (except fo
2009/9/18 Benoit Chesneau :
> And sometimes you need to support full uri spec. For example %2F is
> different from / . Actually if all url is decoded you don't know if the
> client request was %2F or /, you just get a /. Which is annoying. It causes
> some problem with some api ,I'm thinking to co
2009/9/18 Armin Ronacher :
> Hi,
>
> For this topic I would love to remember everybody that the web is
> currently changing and will even more change in the future which will
> probably also mean that a lot of what we're doing currently might not be
> common practise in the near future.
>
> WSGI is
2009/9/18 René Dudfield :
> On Fri, Sep 18, 2009 at 11:21 AM, Graham Dumpleton
> wrote:
>> 2009/9/18 Benoit Chesneau :
>>> And sometimes you need to support full uri spec. For example %2F is
>>> different from / . Actually if all url is decoded you don't know i
2009/9/19 Armin Ronacher :
> Graham's suggestion for URL encodings means that the URL encoding would
> ahve to be passed to the WSGI server from outside (he proposed the
> apache config as an example). This means that the application behavior
> will change based on the server configuration, causin
2009/9/20 Armin Ronacher :
> For that I would rather go like this:
>
> WSGI 1.0 stays the same as PEP 0333 currently is
> WSGI 1.1 becomes what Ian and I added to PEP 0333
> WSGI 2.0 becomes a modified version of PEP
> WSGI 3.0 like XXX but drops start_response
>
>
> ..
2009/9/20 Armin Ronacher :
> Hi,
>
> I know I pretty much SPAM the list here now which is why I added all the
> changes of WSGI 1.0 and what could become WSGI 1.1 into a repo on
> bitbucket as two PEPS:
>
> http://bitbucket.org/ianb/wsgi-peps/src/
>
>
> pep-0333.txt
>
> This is basically just a new
2009/9/21 Armin Ronacher :
>> IMO, this strongly suggests that it's the stdlib or Python 3 that's
>> broken here. How much of the stdlib are we talking about needing to
>> reimplement, aside from cgi.FieldStorage?
> I'm already creating a patch for urllib which currently requires
> unicode. I'm n
2009/9/21 P.J. Eby :
> At 08:48 AM 9/20/2009 -0400, Etienne Robillard wrote:
>>
>> Good plan but I'm afraid now only a bunch of elite people on this list
>> is going to remember all the details on theses "upcoming"
>> specifications. Why the rush to specify WSGI 3.0 and not focus
>> mainly on the n
2009/9/21 René Dudfield :
> On Mon, Sep 21, 2009 at 9:46 AM, Georg Brandl wrote:
>> René Dudfield schrieb:
>>> On Mon, Sep 21, 2009 at 8:10 AM, Chris McDonough
>>> wrote:
OTOH, I suspect the Python 3 stdlib is still broken if it requires native
strings in various places (and prohi
2009/9/21 René Dudfield :
> On Mon, Sep 21, 2009 at 2:46 AM, Robert Brewer wrote:
> ...
>> I want something in between so I don't have to wait months or years for
>> WSGI 2. I want to ship a version of CherryPy with Python 3 support last
>> week.
>
> +1 for wsgi 1.1 *very soon* using the "wsgi.url
2009/9/21 René Dudfield :
>
>
> On Mon, Sep 21, 2009 at 11:30 AM, Graham Dumpleton
> wrote:
>>
>> 2009/9/21 René Dudfield :
>> > On Mon, Sep 21, 2009 at 9:46 AM, Georg Brandl wrote:
>> >> René Dudfield schrieb:
>> >>> On
2009/9/21 René Dudfield :
>
>
> On Mon, Sep 21, 2009 at 11:42 AM, Graham Dumpleton
> wrote:
>>
>> 2009/9/21 René Dudfield :
>> > On Mon, Sep 21, 2009 at 2:46 AM, Robert Brewer
>> > wrote:
>> > ...
>> >> I want something in between s
2009/9/21 René Dudfield :
> On Mon, Sep 21, 2009 at 1:27 PM, Armin Ronacher
> wrote:
>> Hi,
>>
>> René Dudfield wrote:
>>> That's all the arguing and explaining I'll do on this - I'm not going
>>> to rewrite cherrypy for you as proof.
>> If it just puts a burden on implementors on the client and s
2009/9/22 Henry Precheur :
> On Mon, Sep 21, 2009 at 03:26:35PM -0700, Robert Brewer wrote:
>> It looks simpler until you have a site that is not primarily utf-8. In
>> that case, you multiply your (1 line * number of middlewares in the WSGI
>> stack * each request).
>> With wsgi.uri_encoding you g
2009/9/22 Mark Nottingham :
> Most things is not the Web. How will you handle serving images through WSGI?
> Compressed content? PDFs?
You are perhaps misunderstanding something. A WSGI application still
should return bytes.
The whole concept of any sort of fallback to allow unicode data to be
r
the numerous discussions this spawned at:
http://groups.google.com/group/python-web-sig?lnk=
as the current thinking isn't exactly what I blogged about and has
shifted a bit as the discussion has progressed.
Graham
> On 22/09/2009, at 12:07 PM, Graham Dumpleton wrote:
>
>
Armin has fast asleep now, so my shift. :-)
He did point me to this specific email for closer attention,
indicating issues with QUERY_STRING and wsgi.uri_encoding due to
something mentioned here. I didn't quite get what he was talking
about, but then I believe he has some wrong statements in his P
2009/9/22 Henry Precheur :
> On Mon, Sep 21, 2009 at 07:40:54PM -0700, Robert Brewer wrote:
>> The decoding doesn't change spontaneously.
>> You either get the correct one or you get an incorrect one. If it's
>> incorrect, you fix it, one time, via a WSGI component which you've
>> configured to det
2009/9/22 P.J. Eby :
> At 07:21 PM 9/21/2009 -0700, Robert Brewer wrote:
>>
>> I've never proposed that WSGI make choices for people. I'm simply saying
>> that a configurable server, with a sane, perfectly-reversible default, is
>> the simplest thing that could possibly work.
>
> Actually, latin-1
2009/9/22 Ian Bicking :
> On Mon, Sep 21, 2009 at 6:16 PM, Graham Dumpleton
> wrote:
>>
>> > Of course you can directly use `environ['some_key']` if you know you'll
>> > get the 'right' encoding all the time. But when the encodin
2009/9/22 Ian Bicking :
> On Tue, Sep 22, 2009 at 12:21 AM, Graham Dumpleton
> wrote:
>>
>> That may be fine for pure Python web servers where you control the
>> split of REQUEST_URI into SCRIPT_NAME and PATH_INFO in the first place
>> but don't have that luxur
2009/9/22 P.J. Eby :
> I'm tending to flip-flop a bit myself
For the record, I am doing that as well.
Graham
___
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
nse status message, headers
> and body to WSGI implementations.
Same as the WSGI PEP.
http://www.python.org/dev/peps/pep-0333/
Nothing has changed in that respect.
Graham
> Cheers,
>
>
> On 22/09/2009, at 12:26 PM, Graham Dumpleton wrote:
>
>> 2009/9/22
Don't really want to go
explaining it all again.
Graham
> Cheers,
>
> On 22/09/2009, at 4:07 PM, Graham Dumpleton wrote:
>
>> 2009/9/22 Mark Nottingham :
>>>
>>> OK, that's quite exhaustive.
>>>
>>> For the benefit of those of us j
fication and not an IRC channel manned by ticket monkeys. :-(
Graham
> Thanks,
>
>
> On 22/09/2009, at 4:36 PM, Graham Dumpleton wrote:
>
>> 2009/9/22 Mark Nottingham :
>>>
>>> So, what advice do you propose about decoding bytes into strings for the
&
mind
that you are just the help desk and don't want to put any effort into
the relationship, it is hard to try and be that advisor.
So, I felt a bit like a help desk in the way I interpreted your comments.
Graham
> On 22/09/2009, at 4:44 PM, Graham Dumpleton wrote:
>
>> 2009/9
Sorry, after having had a bit of think while eating lunch, I am going
to throw up another point of view on this whole issue. So, sit back
and be just a little bit concerned.
WSGI stands for Web Server GATEWAY Interface.
My understanding is that right back at the beginning WSGI was purely
intended
2009/9/24 P.J. Eby :
>> Anyway, that is the thought. Should we be looking at WSGI as a set of
>> layers instead of assuming we have to push unicode into the gateway
>> interface layer?
>
> These are not mutually exclusive options. However, the set of layers thing,
> if I'm understanding it correct
2009/9/28 Ian Bicking :
> I tried implementing some code to convert REQUEST_URI (the raw request URL)
> and CGI-style SCRIPT_NAME/PATH_INFO into a raw script_name/path_info.
> http://bitbucket.org/ianb/wsgi-peps/src/tip/request_uri.py (python 2)
> http://bitbucket.org/ianb/wsgi-peps/src/tip/req
2009/11/27 And Clover :
> Ian Bicking wrote:
>
>> The proposal that seemed to work best was to keep the environ as str
>> (i.e.,
>> unicode in Python 3), and eliminate the problematic SCRIPT_NAME and
>> PATH_INFO, replacing them with url-encoded values.
>
> Ah, OK, if that's where we got to I'm hap
Please ensure you have also all read:
http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html
I will post again later in detail when have some time to explain a few
more points not mentioned in that post and where people aren't quite
understanding the reasoning for doing thi
accusations that am highjacking
the process.
An answer sooner rather than later would be appreciated on the
wsgi.version issue.
Graham
2009/11/28 Graham Dumpleton :
> Please ensure you have also all read:
>
> http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html
&
2009/11/29 Graham Dumpleton :
> After reading my prior blog posts where I explained my reasoning
> behind the changes, I will acknowledge that I haven't explained some
> stuff very well and people are failing to understand or getting wrong
> idea about why something is being sugge
2009/11/29 James Y Knight :
> On Nov 28, 2009, at 10:44 PM, Graham Dumpleton wrote:
>> Either way, since there seemed to be objections at some level on every
>> point, and since I really really have no enthusiasm for this stuff any
>> more or of fighting for any change,
2009/12/7 Manlio Perillo :
> Graham Dumpleton ha scritto:
>
> Note: I'm sending the entire message to the mailing list.
>
>> 2009/12/7 Manlio Perillo :
>>> Hi.
>>>
>>> I'm playing with Python 3.x, current revision.
>>>
>>
On 28 March 2010 06:10, Manlio Perillo wrote:
> Hi.
>
> Some time ago, someone reported me that an application embedded in Nginx
> with my WSGI module failed to execute, since in my implementation the
> wsgi.errors object does not implement the .close method.
>
> The same object type is used to re
On 28 March 2010 22:21, Manlio Perillo wrote:
> Graham Dumpleton ha scritto:
>> [...]
>>> Unfortunately I never got to know what application or framework was
>>> causing the problem.
>>>
>>> Any idea?
>>
>
> Sorry, my question was not cle
On 30 March 2010 19:27, Manlio Perillo wrote:
> Manlio Perillo ha scritto:
>> Hi.
>>
>> Some time ago, someone reported me that an application embedded in Nginx
>> with my WSGI module failed to execute, since in my implementation the
>> wsgi.errors object does not implement the .close method.
>>
>
On 9 April 2010 21:00, Manlio Perillo wrote:
> I have started to write an asynchronous WSGI implementation for Twisted Web.
>
> The standard implementation execute the WSGI application in a separate
> thread.
> twsgi will instead execute the application in the main Twisted thread.
>
> The advantag
On 9 April 2010 21:29, Manlio Perillo wrote:
> Graham Dumpleton ha scritto:
>> [...]
>>> - the name will be 'wsgiorg.suspend' instead of 'wsgi.pause_output'
>>>
>>> The wsgiorg namespace is used, since the plan is to have it
>
On 9 April 2010 22:15, Manlio Perillo wrote:
> Graham Dumpleton ha scritto:
>> [...]
>>> But since the write callable **can** be implemented in a middleware
>>> (using greenlets) and since middlewares *can* be configured inside WSGI
>>> gateway, implementa
On 9 April 2010 07:53, P.J. Eby wrote:
>> Also, note that with Nginx (as with Apache, if I'm not wrong), even if
>> application yields small strings, the server can still do some buffering
>> in order to increase performance.
>
> In which case, it's in violation of the WSGI spec. The spec require
On 10 April 2010 23:04, Chris Dent wrote:
> On Thu, 8 Apr 2010, P.J. Eby wrote:
>
>> This is also a good time for people to learn that generators are usually a
>> *very bad* way to write WSGI apps - yielding is for server push or sending
>> blocks of large files, not tiny strings. In general, if
On 12 April 2010 06:07, Manlio Perillo wrote:
> I'm not sure about the correct procedure to follow, I hope it is not a
> problem.
>
> I here propose the x-wsgiorg.suspend to be accepted as official WSGI
> extension, using the wsgiorg namespace.
>
> The extension is documented in doc/wsgiorg.suspen
On 12 April 2010 21:25, Manlio Perillo wrote:
> Graham Dumpleton ha scritto:
>> On 12 April 2010 06:07, Manlio Perillo wrote:
>>> I'm not sure about the correct procedure to follow, I hope it is not a
>>> problem.
>>>
>>> I here propose the
On 13 April 2010 00:39, Manlio Perillo wrote:
> P.J. Eby ha scritto:
>> At 01:25 PM 4/12/2010 +0200, Manlio Perillo wrote:
>>> The purpose of the extension if to just have a standard interface that
>>> WSGI applications can use to take advantage of the possibility, offered
>>> by asynchronous serv
On 13 April 2010 18:22, Manlio Perillo wrote:
> Graham Dumpleton ha scritto:
>> [...]
>>> Just yielding an empty string does not give the server some important
>>> informations.
>>>
>>> As an example, with x-wsgi.suspend application can specify
On 13 April 2010 20:41, Manlio Perillo wrote:
>>> So, when executing a sub request, it is necessary to flush (that is,
>>> send to Nginx, in my case) the content generated from the template
>>> before the sub request is done.
>>
>> This seems to only makes sense if you're saying that the subreques
On 13 April 2010 20:59, Benoit Chesneau wrote:
> On Thu, Apr 8, 2010 at 4:53 PM, P.J. Eby wrote:
>> At 04:08 PM 4/8/2010 +0200, Manlio Perillo wrote:
>>>
>>> Hi.
>>>
>>> Some time ago I objected the decision to remove start_response function
>>> from next version WSGI, using as rationale the fact
On 13 April 2010 21:20, Dirkjan Ochtman wrote:
> On Tue, Apr 13, 2010 at 13:13, Graham Dumpleton
> wrote:
>> There is no such thing as a WSGI 2.0 PEP and there is no proper
>> concensus either on what it should look like. Thus if you see anything
>> claiming to implement
On 13 April 2010 21:46, Dirkjan Ochtman wrote:
> On Tue, Apr 13, 2010 at 13:39, Graham Dumpleton
> wrote:
>> WSGI 2.0 isn't about Python 3.X, it is about removing start_response().
>
> Okay, so it is orthogonal, right?
>
>> Python 3.X support can be catered f
On 13 April 2010 22:12, Dirkjan Ochtman wrote:
> On Tue, Apr 13, 2010 at 14:01, Graham Dumpleton
> wrote:
>> They are not simplications. They are clarifications or just describing
>> existing practice. They are not necessarily mod_wsgi specific.
>
> Sorry, I didn&#
On 13 April 2010 23:55, Dirkjan Ochtman wrote:
> On Tue, Apr 13, 2010 at 14:46, Graham Dumpleton
> wrote:
>> The last attempt was to have WSGI 1.1 as clarifications and Python 3.X.
>>
>> And when I say 'last attempt', yes there have been people who have
&g
On 15 April 2010 02:53, Manlio Perillo wrote:
> Dirkjan Ochtman ha scritto:
>> On Tue, Apr 13, 2010 at 14:46, Graham Dumpleton
>> wrote:
>>> The last attempt was to have WSGI 1.1 as clarifications and Python 3.X.
>>>
>>> And when I say 'las
gt; --- pep-0333.txt 2010-04-15 14:46:02.0 +0200
> +++ wsgi-1.1.txt 2010-04-15 14:51:39.0 +0200
> @@ -1,114 +1,124 @@
> -PEP: 333
> -Title: Python Web Server Gateway Interface v1.0
> +PEP:
> +Title: Python Web Server Gateway Interface 1.1
>
On 16 April 2010 11:41, Graham Dumpleton wrote:
> I haven't read what you have done yet
And still haven't. Don't know when I will get a chance to do so.
Two points from a quick scan of emails.
1. The following section of PEP needs to be updated:
"""
1417 A
On 16 April 2010 13:29, Paul Davis wrote:
> On Thu, Apr 15, 2010 at 10:08 PM, Graham Dumpleton
> wrote:
>> On 16 April 2010 11:41, Graham Dumpleton wrote:
>>> I haven't read what you have done yet
>>
>> And still haven't. Don't know when I wil
On 16 April 2010 15:19, Paul J Davis wrote:
>
>
> On Apr 15, 2010, at 11:53 PM, Graham Dumpleton
> wrote:
>
>> On 16 April 2010 13:29, Paul Davis wrote:
>>> On Thu, Apr 15, 2010 at 10:08 PM, Graham Dumpleton
>>> wrote:
>>>> On 16 April
On 26 May 2010 05:58, Deron Meranda wrote:
> I'm trying to use httplib to make a PUT request. I'd like to
> be able to correctly use the 100-continue expectation
> handshake as HTTP/1.1 recommends, such that I wait for
> a 100 status code back before I send the body. The only
> examples I've fou
On 26 May 2010 15:19, Deron Meranda wrote:
> On Wed, May 26, 2010 at 12:32 AM, Graham Dumpleton
> wrote:
>> Bigger problem may be to find a server which actually supports
>> 100-continue in the way one would expect it to work.
>
> Fortunately in my specific case that&#
Can you please join the Python WEB-SIG and continue the existing
conversation there.
http://groups.google.com/group/python-web-sig?lnk=
At the time I was merely facilitating a discussion and am not an
expert on the issues.
I have cc'd the web-sig for those who still may be interested in this.
On 29 June 2010 08:41, P.J. Eby wrote:
> At 03:43 PM 6/28/2010 -0600, Aaron Fransen wrote:
>>
>> Using mod_wsgi on Apache doesn't seem to exhibit that behavior.
>
> You may need "WSGIOutputBuffering Off" in your config; see:
>
> http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIOut
On 29 June 2010 05:01, Aaron Fransen wrote:
> One of the nice things about mod_python is the req.write() function.
One thing I should warn you about req.write() in Apache is that for
streaming data as you seem to be using it, it will accumulate memory
against a request for each write call and tha
On 29 June 2010 23:37, Aaron Fransen wrote:
> Fortunately we're not talking about a huge amount of data here, basically
> just a couple of notices to keep the user happy (less than 1K usually).
>
> When using yield, it's as if the module where the yield command is run is
> completely ignored. The
On 30 June 2010 02:14, Aaron Fransen wrote:
> Couple more things I've been able to discern.
>
> The first happened after I "fixed" the html code. Originally under
> mod_python, I guess I was cheating more than a little bit by sending
> code blocks twice, once for the incremental notices, once for
On 30 June 2010 21:35, Aaron Fransen wrote:
>
>
> On Tue, Jun 29, 2010 at 6:17 PM, Graham Dumpleton
> wrote:
>>
>> On 30 June 2010 02:14, Aaron Fransen wrote:
>> > Couple more things I've been able to discern.
>> >
>> > The first
On 30 June 2010 22:26, Graham Dumpleton wrote:
> On 30 June 2010 21:35, Aaron Fransen wrote:
>>
>>
>> On Tue, Jun 29, 2010 at 6:17 PM, Graham Dumpleton
>> wrote:
>>>
>>> On 30 June 2010 02:14, Aaron Fransen wrote:
>>> > Couple mor
On 30 June 2010 22:55, Aaron Fransen wrote:
>
>
> On Wed, Jun 30, 2010 at 6:26 AM, Graham Dumpleton
> wrote:
>>
>> On 30 June 2010 21:35, Aaron Fransen wrote:
>> >
>> >
>> > On Tue, Jun 29, 2010 at 6:17 PM, Graham Dumpleton
>> > wr
>
> If I'm not getting the results I should be, then obviously I'm doing
> something wrong.
>
> I understand the danger of having a long-running web process (hence the
> reason I have a lot of virtual machines in the live environment using
> mod_python right now) but
On 6 July 2010 21:02, Dirkjan Ochtman wrote:
> On Tue, Jul 6, 2010 at 12:50, Graham Dumpleton
> wrote:
>> In the code example I posted I never had a 'return' statement in same
>> function as 'yield'. You shouldn't be mixing the two.
>
> Well, yo
On 14 July 2010 14:43, Ian Bicking wrote:
> So... there's been some discussion of WSGI on Python 3 lately. I'm not
> feeling as pessimistic as some people, I feel like we were close but just
> didn't *quite* get there.
What I took from the discussion wasn't that one couldn't specify a
WSGI inter
On 14 July 2010 15:04, Graham Dumpleton wrote:
> On 14 July 2010 14:43, Ian Bicking wrote:
>> So... there's been some discussion of WSGI on Python 3 lately. I'm not
>> feeling as pessimistic as some people, I feel like we were close but just
>> didn't *quite*
On 14 July 2010 15:18, Ian Bicking wrote:
> On Wed, Jul 14, 2010 at 12:04 AM, Graham Dumpleton
> wrote:
>>
>> On 14 July 2010 14:43, Ian Bicking wrote:
>> > So... there's been some discussion of WSGI on Python 3 lately. I'm not
>> > feeling as p
On Friday, July 16, 2010, And Clover wrote:
> On 07/14/2010 06:43 AM, Ian Bicking wrote:
>
>
> There's only a couple tricky keys: SCRIPT_NAME, PATH_INFO,
> and HTTP_COOKIE.
>
>
> (And of those, PATH_INFO is the only one that really matters, in that no-one
> really uses non-ASCII script filenames,
On Saturday, July 17, 2010, Ian Bicking wrote:
> On Fri, Jul 16, 2010 at 6:20 PM, Chris McDonough wrote:
>
>
>
>> What are the concrete problems you envision with text request headers,
>> text (URL-quoted) path, and text response status and headers?
>
> Documentation is the main reason. For exam
On Friday, July 16, 2010, And Clover wrote:
> On 07/14/2010 06:43 AM, Ian Bicking wrote:
>
>
> There's only a couple tricky keys: SCRIPT_NAME, PATH_INFO,
> and HTTP_COOKIE.
>
>
> (And of those, PATH_INFO is the only one that really matters, in that no-one
> really uses non-ASCII script filenames,
On Saturday, July 17, 2010, Ian Bicking wrote:
> On Fri, Jul 16, 2010 at 4:33 AM, And Clover wrote:
>
>
> On 07/14/2010 06:43 AM, Ian Bicking wrote:
>
>
> There's only a couple tricky keys: SCRIPT_NAME, PATH_INFO,
> and HTTP_COOKIE.
>
>
>
> (And of those, PATH_INFO is the only one that really mat
On Saturday, July 17, 2010, Ian Bicking wrote:
> On Fri, Jul 16, 2010 at 12:28 PM, Chris McDonough wrote:
>
>
> On Fri, 2010-07-16 at 11:07 -0500, Ian Bicking wrote:
>
>> And this doesn't help with Python 3: either we have byte values of
>> SCRIPT_NAME and PATH_INFO in Python 3, or we have text v
On Saturday, July 17, 2010, Gustavo Narea wrote:
> Hello,
>
> Ian said:
>> Having two ways of expressing the same information will lead to bugs
>> related to which data is canonical. If an application is using
>> SCRIPT_NAME/PATH_INFO and then updates those values in any way, and
>> wsgi.raw_scri
On Saturday, July 17, 2010, Ian Bicking wrote:
> On Fri, Jul 16, 2010 at 1:40 PM, P.J. Eby wrote:
>
>
> At 11:07 AM 7/16/2010 -0500, Ian Bicking wrote:
>
> And this doesn't help with Python 3: either we have byte values of
> SCRIPT_NAME and PATH_INFO in Python 3, or we have text values. I thin
On Saturday, July 17, 2010, Graham Dumpleton wrote:
> On Saturday, July 17, 2010, Ian Bicking wrote:
>> On Fri, Jul 16, 2010 at 1:40 PM, P.J. Eby wrote:
>>
>>
>> At 11:07 AM 7/16/2010 -0500, Ian Bicking wrote:
>>
>> And this doesn't help
On Saturday, July 17, 2010, Ian Bicking wrote:
> On Sat, Jul 17, 2010 at 12:38 AM, Graham Dumpleton
> wrote:
>
>
> On Friday, July 16, 2010, And Clover wrote:
>> On 07/14/2010 06:43 AM, Ian Bicking wrote:
>>
>>
>> There's only a couple tricky keys
On Saturday, July 17, 2010, Antoine Pitrou wrote:
> Ian Bicking writes:
>>
>> So... there's been some discussion of WSGI on Python 3 lately.
>> I'm not feeling as pessimistic as some people, I feel like we were close
>> but just didn't *quite* get there.
>> Here's my thoughts:
>> * Everyone agree
On 17 July 2010 22:30, wrote:
> On Fri, 16 Jul 2010, P.J. Eby wrote:
>
>> At 02:28 PM 7/16/2010 -0500, Ian Bicking wrote:
>> There should be one, and preferably *only* one, obvious way to do it.
>>
>> And given that HTTP is inherently a bunch of bytes, bytes is the one
>> obvious way.
>
> I think
Go back through my blog and read some of the posts there so you have
some of the history. Recent discussions build on some of the stuff
there and I don't think anyone has the time to keep explaining all
this to every new person who comes along.
Graham
On Monday, July 19, 2010, Aaron Watters wrot
On 19 July 2010 03:19, P.J. Eby wrote:
> At 01:01 PM 7/18/2010 +1000, Graham Dumpleton wrote:
>>
>> This is on the basis that if people are going to have to rewrite their
>> code
>> a fair bit to handle bytes everywhere,
>
> What you mean by "rewrite their co
On Tuesday, July 20, 2010, Etienne Robillard wrote:
>
>
>
>
>
>
>
>
>
>
> AFAICT, the main difference is that under a
> bytes-only regime, the changes should be more consistent/mechanical, i.e.,
> able to be performed by relatively superficial code inspection.
>
>
>
> The problem in all these
a script could
> be written to
> port WSGI 1 apps to WSGI 2, assuming such a spec exists and stipulates
> how to parse
> http headers in Python 3...
>
> Regards,
>
> Etienne
>
> Graham Dumpleton wrote:
>
> On Tuesday, July 20, 2010, Etienne Robillard
>
1 - 100 of 353 matches
Mail list logo
