Re: [Web-SIG] Collating follow-up on the future of WSGI

ke in smtp, imap, ... so the servers that >> implement a specific extension can legally published it. Would it work for >> you? > > Since there is nothing in WSGI environ called wsgi.thread now I have no idea > what you are really suggesting here. > > Graha

Re: [Web-SIG] Collating follow-up on the future of WSGI

s that > implement a specific extension can legally published it. Would it work for > you? Since there is nothing in WSGI environ called wsgi.thread now I have no idea what you are really suggesting here. Graham > benoit > > On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton <ma

Re: [Web-SIG] Collating follow-up on the future of WSGI

> On 21 Jan 2016, at 2:48 AM, Benoit Chesneau wrote: > > > > On Wed, Jan 20, 2016 at 1:57 AM Robert Collins > wrote: > On 20 January 2016 at 12:04, Benoit Chesneau > wrote: > > > > > not at all. But I made the assumption that the

Re: [Web-SIG] Collating follow-up on the future of WSGI

> On 20 Jan 2016, at 11:24 PM, André Malo wrote: > > * Graham Dumpleton wrote: > >>> On 20 Jan 2016, at 10:25 PM, André Malo wrote: > >>> Regarding chunked requests - in my own WSGI implementation I went the >>> most pragmatic way and simply p

Re: [Web-SIG] Collating follow-up on the future of WSGI

> On 20 Jan 2016, at 10:25 PM, André Malo wrote: > > * Cory Benfield wrote: > >>> On 20 Jan 2016, at 06:04, Graham Dumpleton >>> wrote: >>> >>> For response content, if a WSGI application currently doesn’t set a >>> Content-Length

Re: [Web-SIG] Collating follow-up on the future of WSGI

> On 20 Jan 2016, at 8:56 AM, Robert Collins wrote: > >> REQUEST_URI environ variable >> >> >> Multiple contributors expressed an interest in bringing this environment >> variable into WSGI directly, making it a required part of the environ >> dictionary. An alter

Re: [Web-SIG] Collating follow-up on the future of WSGI

> On 20 Jan 2016, at 10:57 AM, Robert Collins wrote: > > On 20 January 2016 at 12:04, Benoit Chesneau wrote: > >> >> not at all. But I made the assumption that the wsgi server maintained a >> thread directly or not where the python application is running . >> >> In any case there is some sor

Re: [Web-SIG] Collating follow-up on the future of WSGI

> On 20 Jan 2016, at 8:56 AM, Robert Collins wrote: > >> >> Chunked Transfer Encoding >> ~ >> >> It would be nice to formalise chunked transfer encoding in WSGI. Currently >> there is no way to signal to applications that chunked transfer encoding is >> in use by the

Re: [Web-SIG] Collating follow-up on the future of WSGI

> On 20 Jan 2016, at 8:29 AM, Benoit Chesneau wrote: > > > > On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton <mailto:graham.dumple...@gmail.com>> wrote: > >> On 20 Jan 2016, at 7:43 AM, Benoit Chesneau > <mailto:bchesn...@gmail.com>> wrote: &

Re: [Web-SIG] Collating follow-up on the future of WSGI

> On 20 Jan 2016, at 7:43 AM, Benoit Chesneau wrote: > > I will make a more complete answer soon. But about: > > > > Socket Escape Hatch > ~~~ > > Aside from Benoit, server operators were unanimously dismissive of the idea > of a socket 'escape hatch'. In general it seems li

Re: [Web-SIG] Collating follow-up on the future of WSGI

> On 20 Jan 2016, at 2:55 AM, Cory Benfield wrote: > > Content Lengths > ~~~ > > We should clarify in the new specification that an application that reads > beyond the logical length of the request as given by CONTENT_LENGTH will have > its reads return immediately with the empty

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 10:19 PM, Cory Benfield wrote: > > >> On 6 Jan 2016, at 09:48, Graham Dumpleton wrote: >> >> If this does solve the push issue, what is there in HTTP/2 then that one >> couldn’t do via the existing WSGI interface? > > Well, plen

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 5 Jan 2016, at 10:31 PM, Graham Dumpleton > wrote: > >>> For example, mod_wsgi already supports HTTP/2 by virtue of the fact that >>> the mod_h2 module in Apache exists. The existing internal APIs of Apache >>> and how mod_wsgi uses those means tha

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 12:13 AM, Benoit Chesneau wrote: > > So for me what should be WSGI 2? WSGI 2 should add against WSGI 1 the > following: > > - tell to the application it is actually an HTTP2 request (maybe populating a > wsgi.http2 true env) In CGI implementations you would for HTTP/1.1 a

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 9:27 AM, chris.d...@gmail.com wrote: > > On Wed, 6 Jan 2016, Graham Dumpleton wrote: > >> >>> On 6 Jan 2016, at 12:09 AM, chris.d...@gmail.com wrote: >>> >>> As someone who writes their WSGI applications as functions that take &

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 9:19 AM, Graham Dumpleton > wrote: > >> On 6 Jan 2016, at 12:09 AM, chris.d...@gmail.com >> <mailto:chris.d...@gmail.com> wrote: >> >> As someone who writes their WSGI applications as functions that take >> `start_respons

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 12:09 AM, chris.d...@gmail.com wrote: > > As someone who writes their WSGI applications as functions that take > `start_response` and `environ` and doesn't bother with much > framework the things I would like to see in a minor revision to WSGI > are: > > * A consistent way to

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> I have roughly the same convictions as Graham Dumpleton. If you want to > support HTTP/2 and WebSockets, don’t start with design decisions anchored in > CGI. Figure out what a simple and flexible API for these new protocols would > be, specify it, implement it, and make sure it de

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 5 Jan 2016, at 10:57 PM, Graham Dumpleton > wrote: > > >> On 5 Jan 2016, at 10:26 PM, Cory Benfield > <mailto:c...@lukasa.co.uk>> wrote: >> >> Forwarding this message from the django-developers list. >> >> Hi Cory, >> >

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 5 Jan 2016, at 8:40 PM, Cory Benfield wrote: > > >> On 5 Jan 2016, at 00:12, Graham Dumpleton > <mailto:graham.dumple...@gmail.com>> wrote: >> >> >>> On 4 Jan 2016, at 11:27 PM, Cory Benfield >> <mailto:c...@lukasa.co.uk>>

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 4 Jan 2016, at 11:27 PM, Cory Benfield wrote: > > All, > > **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do > it at all?** > > It’s a new year, and that means it’s time for another attempt to get WSGI 2.0 > off the ground. Many of you may remember that we att

Re: [Web-SIG] REMOTE_ADDR and proxys

On 13/10/2014, at 11:26 PM, Benoit Chesneau wrote: > > > On Sun, Oct 12, 2014 at 11:38 PM, Robert Collins > wrote: > On 30 September 2014 11:47, Alan Kennedy wrote: > > > [Robert] > >> So it sounds like it should be the responsibility of a middleware to > >> renormalize the environment? >

Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging

On 07/10/2014, at 7:15 AM, PJ Eby wrote: > As before, you can find a "living" HTML version of the draft in progress at: > > https://gist.github.com/pjeby/62e3892cd75257518eb0 > > (In addition to nice formatting, it also has a clickable table of contents.) > > After the next round of feedbac

Re: [Web-SIG] WSGI for HTTP/2.0 ?

On 20/09/2014, at 3:49 PM, Roberto De Ioris wrote: > I can help a bit (i am the uWSGI lead developer and a nginx and Cherokee > contributor, and i have already implemented a spdy3 server last year) > > I honestly think that WSGI by itself needs a complete rewrite/rethink to > be adapted to mode

Re: [Web-SIG] [python-tulip] Re: [Python-Dev] wsgi validator with asynchronous handlers/servers

can not handle true post-response > hooks. > > The closest hack I found is this: > https://modwsgi.readthedocs.org/en/latest/developer-guides/registering-cleanup-code.html > > > As discussed by Graham Dumpleton here > https://groups.google.com/group/modwsgi/msg/d699a

Re: [Web-SIG] [modwsgi] Hop-by-hop headers

Probably better off asking on the Python WEB-SIG. I have cc'd this there. http://www.python.org/community/sigs/current/web-sig/ Someone has probably felt that wsgiref implementation should somehow be checking for things which aren't notionally allowed but which go beyond just API usage checks. Ch

Re: [Web-SIG] question about connection pool, task queue in WSGI

rent WSGI severs would behave differently, especially around process control, but your model of understand is close enough. >> Before hacking into a task queue based on pure wsgi code, I want to make >> sure my view of wsgi is correct. :) Would still suggest you just use an existi

Re: [Web-SIG] question about connection pool, task queue in WSGI

ven both?). After a defined number of requests the wsgi worker > terminates and spawns the next wsgi worker process. > > Before hacking into a task queue based on pure wsgi code, I want to make > sure my view of wsgi is correct. :) > > Please advise! Thanks in advance! > > >

Re: [Web-SIG] question about connection pool, task queue in WSGI

On 12 July 2012 19:50, est wrote: > Hi list, > > I am running a site with django + uwsgi, I have few questions about how WSGI > works. > > 1. Is db connection open/close handled by Django? If it's open/closed per > request, Yes it is. > can we make a connection pool in wsgi level, then multiple

Re: [Web-SIG] Large, fixed latency on every wsgiref response

If on Windows then try using 127.0.0.1 instead of localhost. There are known issues with Windows whereby localhost actually resolves to an IPV6 address of ::1 rather than IPV4 address of 127.0.0.1. For reasons I can't remember, this causes an initial delay in connections. Graham On 8 June 2012 1

Re: [Web-SIG] Large, fixed latency on every wsgiref response

Are you using an IP address or DNS name? http://appletoolbox.com/2010/09/fix-safari-slowness-stalled-page-loads-by-disabling-dns-prefetching/ http://support.apple.com/kb/TS2296 Graham On 8 June 2012 07:09, Matt Chaput wrote: > I'm using Paste script to configure a wsgiref server on Windows. And

Re: [Web-SIG] Fwd: Can writing to stderr be evil for web apps?

On 19 May 2012 22:36, anatoly techtonik wrote: > Hi, > > Martin expressed concerns that using logging module with stderr output > can break web applications, such as PyPI. I couldn't find any proof or > denials for this fact, and it became a showstopper for me for further > contributions to PyPI,

Re: [Web-SIG] Move www.wsgi.org to Read The Docs

Christian The wsgi.org domain has reverted back to point to 'DZUG-Sprints' site rather than to www.wsgi.org or wsgi.readthedocs.org. Can you see what it going on. Thanks. Graham On 20 September 2011 07:42, Graham Dumpleton wrote: > Christian. The DNS entry is actually wrong.

Re: [Web-SIG] A more useful command-line wsgiref.simple_server?

On 2 April 2012 15:08, Graham Dumpleton wrote: > On 2 April 2012 14:54, Sasha Hart wrote: >> I would personally not +x a module file just to serve an app with wsgiref >> from the hashbang line; it's clever but I can't come up with any real >> benefit. A case

Re: [Web-SIG] A more useful command-line wsgiref.simple_server?

On 2 April 2012 14:54, Sasha Hart wrote: > I would personally not +x a module file just to serve an app with wsgiref > from the hashbang line; it's clever but I can't come up with any real > benefit. A case where I'm serving with wsgiref already has to be pretty > trivial and I'm not going to coup

Re: [Web-SIG] A more useful command-line wsgiref.simple_server?

On 31 March 2012 14:36, PJ Eby wrote: > On Fri, Mar 30, 2012 at 5:12 PM, Graham Dumpleton > wrote: >> >> Now when doing mod_wsgi, a similar method of loading each file >> >> separately with a __name__ based on file system path was used to >> ensure each was

Re: [Web-SIG] A more useful command-line wsgiref.simple_server?

On 31 March 2012 06:58, Geoffrey Spear wrote: > On Fri, Mar 30, 2012 at 3:20 PM, Masklinn wrote: >> 2. You seem to have asserted from the start that the default should be >>   mounting modules, but I have seen no evidence or argument in favor of >>   that so far. >> >>   Defaulting to scripts not

Re: [Web-SIG] A more useful command-line wsgiref.simple_server?

On 29 March 2012 21:02, Masklinn wrote: > Moving here as suggested by Terry Reedy as this list may be more > interested than -ideas (note: some feedback already used to revise > the original proposal, and a very basic patch — with no tests — is > provided for the current CPython default branch) >

Re: [Web-SIG] A 'shutdown' function in WSGI

setDaemon(). Graham On 22 February 2012 00:46, Tarek Ziadé wrote: > > > On Tue, Feb 21, 2012 at 1:43 PM, Antoine Pitrou wrote: >> >> Tarek Ziadé writes: >> > >> > >> > On Tue, Feb 21, 2012 at 10:24 AM, Graham Dumpleton >> wrote: >> > ..

Re: [Web-SIG] A 'shutdown' function in WSGI

On 21 February 2012 21:07, Simon Sapin wrote: > Le 21/02/2012 10:31, Graham Dumpleton a écrit : > >> You do realise you are just reinventing context managers? >> >> With this 'application' do requests. > > Indeed. I didn’t want to go too far from the ini

Re: [Web-SIG] A 'shutdown' function in WSGI

On 21 February 2012 21:41, Tarek Ziadé wrote: > > > On Tue, Feb 21, 2012 at 10:24 AM, Graham Dumpleton > wrote: >> >> ... >> >> > But I don't think you can guarantee that everything is still up in >> > memory by >> > the time atexit

Re: [Web-SIG] A 'shutdown' function in WSGI

On 21 February 2012 20:26, Simon Sapin wrote: > Le 21/02/2012 09:23, Tarek Ziadé a écrit : > >>    Instead of having to provide two or three objects separately to a >>    server, how about making the callbacks attributes of the application >>    callable? >> >> >> can you show us an example ? > >

Re: [Web-SIG] A 'shutdown' function in WSGI

On 21 February 2012 18:53, Tarek Ziadé wrote: > > > On Tue, Feb 21, 2012 at 2:39 AM, Graham Dumpleton > wrote: >> >> ... >> >> Overall the best chance of being able to do anything is relying on atexit. >> >> You are though at the mercy of the WSG

Re: [Web-SIG] A 'shutdown' function in WSGI

On 21 February 2012 12:03, Simon Sapin wrote: > Le 21/02/2012 01:18, Chris McDonough a écrit : > >> On Mon, 2012-02-20 at 17:39 -0500, PJ Eby wrote: >>> >>> >  The standard way to do this would be to define an "optional server >>> >  extension" API supplied in the environ; for example, a >>> >  'x

Re: [Web-SIG] Move www.wsgi.org to Read The Docs

me project. Eric, yes, please change the slug. Thanks. Graham On 20 September 2011 06:42, Graham Dumpleton wrote: > Thanks. > > One thing we should do now is create a page with instructions on how > you can contribute changes back via github project. > > Graham > > On 19 Sept

Re: [Web-SIG] Move www.wsgi.org to Read The Docs

Thanks. One thing we should do now is create a page with instructions on how you can contribute changes back via github project. Graham On 19 September 2011 23:30, Christian Theune wrote: > Hi, > > On 09/19/2011 11:33 AM, Christian Theune wrote: >> >> OK, I updated our database. The nameservers

Re: [Web-SIG] Move www.wsgi.org to Read The Docs

On 17 September 2011 03:05, Masklinn wrote: > On 2011-09-16, at 12:20 , Graham Dumpleton wrote: >> On 16 September 2011 19:46, Masklinn wrote: >>> On 2011-09-10, at 22:18 , Graham Dumpleton wrote: >>>> We haven't actually done a push up to ReadTheDocs yet.

Re: [Web-SIG] Move www.wsgi.org to Read The Docs

On 16 September 2011 19:46, Masklinn wrote: > On 2011-09-10, at 22:18 , Graham Dumpleton wrote: >> We haven't actually done a push up to ReadTheDocs yet. >> >> Sorry, just been too busy with work and trip to US. I expect things to >> calm down once get home this

Re: [Web-SIG] Move www.wsgi.org to Read The Docs

Just change: :Title: Waiting for File Descriptor Events :Author: Christopher Stawarz :Discussions-To: Python Web-SIG :Status: Proposed :Created: 11-May-2008 to: Waiting for File Descriptor Events :Author: Christopher Stawarz :Discussions-To: Python Web-SIG :Status:

Re: [Web-SIG] Move www.wsgi.org to Read The Docs

We haven't actually done a push up to ReadTheDocs yet. Sorry, just been too busy with work and trip to US. I expect things to calm down once get home this week. FWIW, have no issues with adding other people to have direct commit rights to wsgiorg project so I am not a bottleneck. Graham On 10 S

Re: [Web-SIG] Move www.wsgi.org to Read The Docs

I'll see if I can find someone at the DjangoCon sprints who might be able to give suggestions of what to do. The sprints are at the offices of Eric from ReadTheDocs, so one would think I might be able to get an answer. On 10 September 2011 06:36, Masklinn wrote: > On 2011-09-10, at 11:45 , Stepha

Re: [Web-SIG] Move www.wsgi.org to Read The Docs

Who then is the specific person who could switch the DNS for www.wsgi.org to direct towards ReadTheDocs when we are ready, Christian? This presumes of course people are happy about this being done. I have been a bit busy myself, but masklinn has been doing a great job at moving the pages into Sphi

Re: [Web-SIG] Move www.wsgi.org to Read The Docs.

orth a try. The site really needs some love. Graham On 19 August 2011 07:23, Masklinn wrote: > On 2011-08-18, at 23:14 , Graham Dumpleton wrote: >> Who owns and manages www.wsgi.org wiki? >> >> The amount of spam the wiki gets now is becoming rediculous. >> >> If we c

[Web-SIG] Move www.wsgi.org to Read The Docs.

Who owns and manages www.wsgi.org wiki? The amount of spam the wiki gets now is becoming rediculous. If we care about the wiki, it is time to take the content in it and dump it in github as a project which can then be loaded up to Read The Docs, with www.wsgi.org directing to that. In the mean t

Re: [Web-SIG] A Python Web Application Package and Format

small problem at a time. Thus please don't think that because I am replying to your message that I am specifically commenting about your plans. See this as a side comment and don't try and evaluate it only in the context of your ideas. > On 2011-04-14 00:53:09 -0700, Graham Dumpl

Re: [Web-SIG] A Python Web Application Package and Format

On 14 April 2011 16:57, Alice Bevan–McGregor wrote: >> 3. Define how to get the WSGI app.  This is WSGI specific, but (1) is >> *not* WSGI specific (it's only Python specific, and would apply well to >> other platforms) > > I could imagine there would be multiple "application types": > > :: WSGI a

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 13 January 2011 12:02, P.J. Eby wrote: > At 02:52 PM 1/12/2011 -0800, Guido van Rossum wrote: >> >> On Wed, Jan 12, 2011 at 2:34 PM, Alice Bevan­McGregor >> wrote: >> > On 2011-01-10 13:12:57 -0800, Guido van Rossum said: >> >> >> >> Ok, now that we've had a week of back and forth about this,

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

On 9 January 2011 12:16, Alice Bevan–McGregor wrote: > On 2011-01-08 09:00:18 -0800, P.J. Eby said: > >> (The next interesting challenge would be to integrate this withGraham's >> proposal for adding cleanup handlers...) > > class MyApplication(object): >   def __init__(self): >       pass # proce

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 8 January 2011 02:55, P.J. Eby wrote: > At 05:27 PM 1/7/2011 +1100, Graham Dumpleton wrote: >> >> Another thing though. For output changed to sys.stdout.buffer. For >> input should we be using sys.stdin.buffer as well if want bytes? > > %&$*()&%!!!  Sorr

Re: [Web-SIG] Python 3 / PEP 3333 (was: PEP 444 / WSGI 2 Async)

On 7 January 2011 18:23, Alice Bevan–McGregor wrote: > On 2011-01-06 21:35:24 -0800, Jacob Kaplan-Moss said: > Other than mod_wsgi, are there any PEP -compliant (or near-compliant) > components in the wild?  Enough to bring a framework to life in Python 3? >  What I see is the chicken-and-egg

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 7 January 2011 17:19, Alice Bevan–McGregor wrote: >> -                    raise exc_info[0], exc_info[1], exc_info[2] >> +                    raise >> exc_info[0](exc_info[1]).with_traceback(exc_info[2]) > > The exception raising syntax has changed; you can not re-raise an exception > using tup

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 7 January 2011 17:22, Graham Dumpleton wrote: > On 7 January 2011 17:13, Graham Dumpleton wrote: >> The version at: >> >> http://svn.python.org/projects/peps/trunk/pep-.txt >> >> still shows: >> >>        elif not headers_sent: >>    

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 7 January 2011 17:13, Graham Dumpleton wrote: > The version at: > > http://svn.python.org/projects/peps/trunk/pep-.txt > > still shows: > >        elif not headers_sent: >             # Before the first output, send the stored headers >             status, resp

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

s\r\n' % status) for header in response_headers: sys.stdout.write('%s: %s\r\n' % header) sys.stdout.write('\r\n') so not using buffer there and also not converting strings written for headers to bytes. Graham On 7 January 2011

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

; On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight wrote: >> On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote: >>> At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote: >>>> Is that the last thing or do I need to go spend some time and write my >>>> own CGI/WSGI bri

Re: [Web-SIG] PEP 444 Goals

2011/1/7 James Y Knight : > > On Jan 6, 2011, at 7:46 PM, Alex Grönholm wrote: > > The WebDAV spec, on the other hand, says > (http://www.webdav.org/specs/rfc2518.html#STATUS_102): > > The 102 (Processing) status code is an interim response used to inform the > client that the server has accepted t

Re: [Web-SIG] PEP 444 Goals

2011/1/7 Alex Grönholm : > 07.01.2011 04:09, Graham Dumpleton kirjoitti: >> >> 2011/1/7 Graham Dumpleton: >>> >>> 2011/1/7 Alex Grönholm: >>>> >>>> 07.01.2011 01:14, Graham Dumpleton kirjoitti: >>>> >>>> One other co

Re: [Web-SIG] PEP 444 Goals

2011/1/7 Graham Dumpleton : > 2011/1/7 Alex Grönholm : >> 07.01.2011 01:14, Graham Dumpleton kirjoitti: >> >> One other comment about HTTP/1.1 features. >> >> You will always be battling to have some HTTP/1.1 features work in a >> controllable way. This i

Re: [Web-SIG] PEP 444 Goals

2011/1/7 Alex Grönholm : > 07.01.2011 01:14, Graham Dumpleton kirjoitti: > > One other comment about HTTP/1.1 features. > > You will always be battling to have some HTTP/1.1 features work in a > controllable way. This is because WSGI gateways/adapters aren't often > dir

Re: [Web-SIG] PEP 444 Goals

server can provide that information, which basically means that only pure Python HTTP/WSGI servers are likely able to provide it without guessing, and in that case such servers usually are always used where WSGI application mounted at root anyway. Graham On 7 January 2011 09:29, Graham Dumpleton

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Can we not let the PEP 444 discussion side track getting PEP sorted out? This is exactly what has happened numerous times before when we have been trying to sort out core issues of WSGI on Python 3. And people wander why I get grumpy now every time this happens. :-( So, where are we at? It se

Re: [Web-SIG] PEP 444 Goals

On 7 January 2011 08:56, Alice Bevan–McGregor wrote: > On 2011-01-06 13:06:36 -0800, James Y Knight said: > >> On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote: >>> >>> :: Making optional (and thus rarely-implemented) features non-optional. >>> E.g. server support for HTTP/1.1 with clarifica

Re: [Web-SIG] CGI in PEP 444

On 5 January 2011 07:04, James Y Knight wrote: > Back to the subject of this thread: A simple CGI server is useful because > it's simple enough that you can include it in the spec, to demonstrate how to > handle various bits of WSGI. And anyone writing a webserver understands CGI, > and can und

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

ould be covered in separate articles or commentaries be people, but given this person was new to it, maybe it is deserving of more explanation in the PEP itself if they were confused. It could also be that the PEP covers it adequately already. I am too tired to read through it again right now. Graham

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

BTW, to what extent are the examples in the PEP meant to be able to work on both Python 2.X and Python 3.X as is. Does it need to be clarified where examples will only work on Python 3.X, in particular the CGI gateway. Graham On 4 January 2011 16:49, Graham Dumpleton wrote: > On 4 January 2

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 4 January 2011 16:39, Guido van Rossum wrote: > On Mon, Jan 3, 2011 at 7:39 PM, Graham Dumpleton > wrote: >> I note one issue which I have expressed concern over previously. In >> section 'Handling the Content-Length Header; it says: >> >> """

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 4 January 2011 15:43, James Y Knight wrote: > > On Jan 3, 2011, at 10:39 PM, Graham Dumpleton wrote: > >> As documented in: >> >>  http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html >> >> the automatic addition of a Content-Lengt

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 4 January 2011 11:43, Guido van Rossum wrote: > On Mon, Jan 3, 2011 at 3:13 PM, Jacob Kaplan-Moss wrote: >> On Sun, Jan 2, 2011 at 9:21 AM, Guido van Rossum wrote: >>> Although [PEP ] is still marked as draft, I personally think of it >>> as accepted; [...] >> >> What does it take to get

Re: [Web-SIG] PEP 444 != WSGI 2.0

On 2 January 2011 16:28, Guido van Rossum wrote: > On Sat, Jan 1, 2011 at 5:02 PM, Graham Dumpleton > wrote: >> Can we please clear up a matter. >> >> GothAlice (don't know off hand there real name), keeps going around >> and claiming: >> >> &quo

Re: [Web-SIG] PEP 444 != WSGI 2.0

can be the only successor for WSGI 1.0. So, if someone comes up with a much better solution, they will be forced to call it something completely different because you are hardly going to be able to go back and say, sorry, we made a mistake and all you people who genuinely thought you were coding to what

Re: [Web-SIG] PEP 444 != WSGI 2.0

On 2 January 2011 12:09, Jonas Galvez wrote: > Graham Dumpleton wrote: >> If the people here who's opinion matters are quite happy for GothAlice >> to hijack the WSGI 2.0 moniker for PEP 444 I will shut up. But if that >> happens, I will voice my objections by simply no

[Web-SIG] PEP 444 != WSGI 2.0

Can we please clear up a matter. GothAlice (don't know off hand there real name), keeps going around and claiming: """ After some discussion on the Web-SIG mailing list, PEP 444 is now "officially" WSGI 2, and PEP is WSGI 1.1 """ In this instance on web.py forum on Google Groups. I have po

Re: [Web-SIG] Is PEP 3333 the final solution for WSGI on Python 3?

On 22 October 2010 11:16, P.J. Eby wrote: > At 10:35 AM 10/22/2010 +1100, Graham Dumpleton wrote: >> >> Any one care to comment on my blog post? >> >> >> >> http://blog.dscpl.com.au/2010/10/is-pep--final-solution-for-wsgi-on.html >> >> As f

[Web-SIG] Is PEP 3333 the final solution for WSGI on Python 3?

Any one care to comment on my blog post? http://blog.dscpl.com.au/2010/10/is-pep--final-solution-for-wsgi-on.html As far as web framework developers commenting, Armin at: http://www.reddit.com/r/Python/comments/du7bf/is_pep__the_final_solution_for_wsgi_on_python/ has said: """Ho

Re: [Web-SIG] WSGI for Python 3

On 30 August 2010 13:07, P.J. Eby wrote: > At 11:16 AM 8/30/2010 +1000, Graham Dumpleton wrote: >> >> Although I almost begged that if we are going to discuss bytes, >> compared to text/unicode, that agreement at least first be made about >> the definition of the

Re: [Web-SIG] WSGI for Python 3

On 30 August 2010 11:02, Ian Bicking wrote: > Ugh... why are we back at bytes again? Because no official decision, by way of a vote or even consensus, has ever been made, the bytes option never goes away. The problem with bytes, before one even tries to compare it to text/unicode option, is that

Re: [Web-SIG] WSGI for Python 3

On 27 August 2010 13:45, P.J. Eby wrote: > At 01:37 AM 8/27/2010 +0200, Armin Ronacher wrote: >> >> Hi, >> >> Is there a status update on that now I missed?  Did something decide on >> bytes for the environment values or are we still unsure about that? > > To the extent we're "unsure", I think the

Re: [Web-SIG] WSGI for Python 3

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 >  

Re: [Web-SIG] WSGI for Python 3

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

Re: [Web-SIG] WSGI for Python 3

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

Re: [Web-SIG] WSGI for Python 3

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

Re: [Web-SIG] WSGI for Python 3

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

Re: [Web-SIG] decoding environ

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

Re: [Web-SIG] WSGI for Python 3

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

Re: [Web-SIG] WSGI for Python 3

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

Re: [Web-SIG] WSGI for Python 3

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

Re: [Web-SIG] WSGI for Python 3

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

Re: [Web-SIG] WSGI for Python 3

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

Re: [Web-SIG] WSGI for Python 3

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

Re: [Web-SIG] WSGI for Python 3

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,

  1   2   3   4   >