Re: [Web-SIG] Web application packaging

I've been doodling around with things, but honestly I've deployed zero Python apps in the last year, so lacking a use case of any kind I find myself rather unfocused, even though I feel a degree of confidence about the approach. Anyway, my indirect doodling is here: https://github.com/ianb/apppkg/

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

I believe Stephan Diehl owns wsgi.org. On Thu, Aug 18, 2011 at 4:14 PM, Graham Dumpleton < graham.dumple...@gmail.com> wrote: > 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 i

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

On Wed, Apr 27, 2011 at 5:21 PM, Daniel Holth wrote: > I stumbled across https://apphosted.com as more web application package > and format 'prior art'. It appears to be an App Engine competitor. According > to their API documentation, their deployment format is an archive containing > a single d

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

On Fri, Apr 15, 2011 at 2:05 PM, Alice Bevan–McGregor wrote: > I want to keep this distinct from anything long-running, which is a much >> more complex deal. >> > > The primary application is only potentially long-running. (You could, in > theory, deploy an app as CGI, but that way lies madness.)

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

uctured?) An application configuration could refer to scripts under different names, to be invoked at different stages. On Thu, Apr 14, 2011 at 1:57 AM, Alice Bevan–McGregor wrote: > On 2011-04-13 18:16:36 -0700, Ian Bicking said: > > While initially reluctant to use zip files, after further d

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

On Thu, Apr 14, 2011 at 2:53 AM, Graham Dumpleton < graham.dumple...@gmail.com> wrote: > 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 > >>

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

While we are focusing on points of contention, there may be more points of consensus, but we aren't talking about those. So, some initial thoughts: While initially reluctant to use zip files, after further discussion and thought they seem fine to me, so long as any tool that takes a zip file can

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

(I'm confused; I just noticed there's a web-sig@python.org and python-web-...@googlegroups.com?) On Mon, Apr 11, 2011 at 2:01 PM, Daniel Holth wrote: > We have more than 3 implementations of this idea, the Python Web > Application Package and Format or WAPAF, including Java's WAR files, Google >

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

On Mon, Apr 11, 2011 at 2:56 AM, Ionel Maries Cristian wrote: > Hello, > > I have few comments: > >- That file layout basically forces you to have your development >environment as close to the production environment. This is especially >visible if you're relying on python c extensions.

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

On Sun, Apr 10, 2011 at 10:29 PM, Alice Bevan–McGregor wrote: > Howdy! > > > On 2011-04-10 19:06:52 -0700, Ian Bicking said: > > There's a significant danger that you'll be creating a configuration >> management tool at that point, not simply a web application d

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

On Sun, Apr 10, 2011 at 6:40 PM, Alice Bevan–McGregor wrote: > On 2011-04-10 16:25:21 -0700, James Mills said: > > +1 too. I would however like to see this idea developed in a generic >> and useable way. ie: No zope/twisted deps or making it fit around >> Django :) >> Ideally it should be useable

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

Hi all. I wrote a blog post. I would be interested in reactions from this crowd. http://blog.ianbicking.org/2011/03/31/python-webapp-package/ Copied to allow responses: At PyCon there was an open space about deployment, and the idea of drop-in applications (Java-WAR-style

Re: [Web-SIG] urllib.unquote in paste.httpserver prevents slashes in path segments

I'll just add that *if* you can design your URL space (you didn't just inherit one), and you want to distinguish path segments from values that contain '/', you can use URLs like: /item/{some/value}/view And then use the matching {}'s to figure out that "some/value" is one path segment. This ma

Re: [Web-SIG] urllib.unquote in paste.httpserver prevents slashes in path segments

It's implied by WSGI itself that the path be unquoted; there's no fix short of changing the specification. On Thu, Mar 17, 2011 at 1:10 PM, Florian Friesdorf wrote: > > I think paste.httpserver.WSGIHandlerMixin.wsgi_setup should not > urllib.unquote the path [1] before setting it in the wsgi en

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

o hijack the WSGI 2.0 moniker for PEP 444 I will shut up. But if that > happens, I will voice my objections by simply not having anything to > do with WSGI 2.0 any more. > > Graham > _______ > Web-SIG mailing list > W

Re: [Web-SIG] PEP 444 / WSGI2 Proposal: Filters to suppliment middleware.

an mean multiple instances applied after dispatch. Encoding and Decoding don't apply to WSGI. Tidy is intrusive and I think questionable on a global level. I don't think the use cases are there. Tightly bound pre-filters and post-filters are particularly problematic. This all seems lik

Re: [Web-SIG] PEP 444 / WSGI2 Proposal: Filters to suppliment middleware.

you have dispatching apps (like paste.urlmap or Routes)? You can still implement this locally of course, as a class that takes an app and input and output filters. -- Ian Bicking | http://blog.ianbicking.org ___ Web-SIG mailing list Web-SIG@pytho

Re: [Web-SIG] PEP 444

aking changes, and the changes are reasonable enough that it's not a complete change. Most of the changes have been discussed as "WSGI 2" for a long time preceding this spec anyway. -- Ian Bicking | http://blog.ianbicking.org ___ Web-SIG ma

Re: [Web-SIG] WSGI server aimed at easy deployment and administration

__ > 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/ianb%40colorstudy.com > -- Ian Bicking | http://blog.ianbicking.org ___ 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

Re: [Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

On Thu, Sep 23, 2010 at 3:23 PM, P.J. Eby wrote: > At 11:17 AM 9/23/2010 -0500, Ian Bicking wrote: > >> I don't see any reason why Location shouldn't be ASCII. Any header could >> have any character put in it, of course, there's just no valid case where >>

Re: [Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

On Thu, Sep 23, 2010 at 11:17 AM, Ian Bicking wrote: > If these headers accidentally contain non-Latin1 characters, the error >> isn't detectable until the header reaches the origin server doing the >> transmission encoding, and it'll likely be a dynamic (and therefor

Re: [Web-SIG] Output header encodings? (was Re: Backup plan: WSGI 1 Addenda and wsgiref update for Py3)

On Thu, Sep 23, 2010 at 11:06 AM, P.J. Eby wrote: > At 12:57 PM 9/21/2010 -0400, Ian Bicking wrote: > >> On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby <<mailto:p...@telecommunity.com >> >p...@telecommunity.com> wrote: >> The Python 3 specific changes are to use:

Re: [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

On Tue, Sep 21, 2010 at 1:17 PM, P.J. Eby wrote: > [trimming reply headers to just web-sig] > > At 12:57 PM 9/21/2010 -0400, Ian Bicking wrote: > > On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby <<mailto:p...@telecommunity.com >> >p...@telecommunity.com> wrote: >

Re: [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

ted with arbitrary combinations of strings and > bytes in order to test compliance. If you want your application to output > strings rather than bytes, you can always use a decorator to do that. (And > a sample one could be provided in wsgiref.) > I agre

Re: [Web-SIG] [Python-Dev] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

sense, making WSGI 1 sensible for Python 3 (as well as other small errata like the size hint) doesn't detract from PEP 444 at all, IMHO. -- Ian Bicking | http://blog.ianbicking.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: h

Re: [Web-SIG] PEP 444 (aka Web3)

a great strategy, but at least it seems like it will create a generally correct result. -- Ian Bicking | http://blog.ianbicking.org ___ 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

Re: [Web-SIG] PEP 444 (aka Web3)

return status, headers, body replacement_app.app = app return replacement_app -- Ian Bicking | http://blog.ianbicking.org ___ 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

Re: [Web-SIG] PEP 444 (aka Web3)

t years of practice have shown it is not used. -- Ian Bicking | http://blog.ianbicking.org ___ 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

Re: [Web-SIG] PEP 444 (aka Web3)

On Fri, Sep 17, 2010 at 2:06 PM, Armin Ronacher wrote: > Hi, > > > On 9/17/10 7:43 PM, Ian Bicking wrote: > >> I'm also not sure what motivated this particular change, but I don't >> have any opinion one way or the other. >> > Motivation is tha

Re: [Web-SIG] PEP 444 (aka Web3)

th header by guessing the length from the response iterable. This must be set by the application itself in all situations. I'm also not sure what motivated this particular change, but I don't have any opinion one way or the other. -- Ian Bicking | http://blog.ianbicking.org __

Re: [Web-SIG] PEP 444 (aka Web3)

On Fri, Sep 17, 2010 at 1:02 PM, Ian Bicking wrote: > I would really like to see concerns over bad gateways not be used to keep > valuable information out of the spec. We want people to use well-configured > gateways that accurately represent requests. There are limits, e.g., in >

Re: [Web-SIG] PEP 444 (aka Web3)

uable information out of the spec. We want people to use well-configured gateways that accurately represent requests. There are limits, e.g., in environments where information is lost. The only really problematic example is losing the distinction between %2f and /, and I think it's reasona

Re: [Web-SIG] PEP 444 (aka Web3)

On Thu, Sep 16, 2010 at 9:59 PM, Armin Ronacher wrote: > On 9/17/10 3:43 AM, Ian Bicking wrote: > >> Not if you are working with the URL-encoded paths. >> > > SCRIPT_NAME / PATH_INFO will always stay unencoded and the current spec > requires the web3.script_name thing

Re: [Web-SIG] PEP 444 (aka Web3)

In general though I have to say that > very few people use wsgi.errors currently, so I don't think this is > a real issue anyways. > It's more of an issue under Python 2, it could probably be ignored with Python 3. Under Python 2 when you have some error condition i

Re: [Web-SIG] PEP 444 (aka Web3)

iter = app(environ) Web3 proposed a different order, but it seems clear from the thread that people prefer the more natural order, and web3 authors don't particularly object. -- Ian Bicking | http://blog.ianbicking.org ___ Web-SIG mailing

Re: [Web-SIG] PEP 444 (aka Web3)

On Thu, Sep 16, 2010 at 12:35 PM, Guido van Rossum wrote: > On Thu, Sep 16, 2010 at 10:01 AM, Ian Bicking wrote: > > Well, reiterating some things I've said before: > > > > * This is clearly just WSGI slightly reworked, why the new name? > > * Why byte values in

Re: [Web-SIG] PEP 444 (aka Web3)

headers, I think we should ignore the HTTP spec. You can put 4k in a Set-Cookie header, such headers aren't easily or safely folded... I think the line length constraint in the HTTP spec isn't a constraint we need to pay attention to. -- Ian Bicking

Re: [Web-SIG] WSGI for Python 3

?q?stuff-with=-escaping?=". Response headers are equivalent to request headers. Response status is constrained by the spec to Latin1, and there are no use cases I know of (even really obscure ones) where it would be necessary to use other encodings. And tha

Re: [Web-SIG] WSGI for Python 3

xpect they won't work. It also doesn't feel particularly *wrong*. The parsed portions of the request and response are mostly ASCII anyway, and the exceptions generally require wonky code anyway so a little transcoding isn't so bad. -- Ian Bicking | h

Re: [Web-SIG] WSGI for Python 3

On Sat, Jul 17, 2010 at 5:57 AM, Armin Ronacher wrote: > On 7/17/10 9:15 AM, Ian Bicking wrote: > >> This is an Apache-specific issue. It definitely doesn't apply to >> paste.httpserver, I doubt CherryPy or wsgiref. I don't really know how >> Nginx or other

Re: [Web-SIG] WSGI for Python 3

On Sat, Jul 17, 2010 at 12:38 AM, Graham Dumpleton < graham.dumple...@gmail.com> 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: SCRIPT_NAME, PATH_INFO, &g

Re: [Web-SIG] WSGI for Python 3

ing should be loud. * As much as possible WSGI should be readable and usable. Maybe most people will use a library, but we also have a lot of libraries that handle WSGI, and it's nice that's been able to happen, so we don't want to make things any harder than they have to be.

Re: [Web-SIG] WSGI for Python 3

s an attacker could encode "." to make things harder. Nevertheless, WSGI servers don't currently guarantee this cleaning. I added it to paste.httpserver, but I don't know one way or the other about any other servers. A quick test shows wsgiref does not clean paths. So apps sh

Re: [Web-SIG] WSGI for Python 3

On Fri, Jul 16, 2010 at 8:46 PM, Ian Bicking wrote: > So... before jumping to conclusions, what's the hard part with using text? > Oh, the one thing that will be silly is cookies, but they are totally nuts already. They can be parsed equally well as bytes or latin1, and best only

Re: [Web-SIG] WSGI for Python 3

y with WSGI. So... before jumping to conclusions, what's the hard part with using text? -- Ian Bicking | http://blog.ianbicking.org ___ 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

Re: [Web-SIG] WSGI for Python 3

On Fri, Jul 16, 2010 at 5:06 PM, Ian Bicking wrote: > On Fri, Jul 16, 2010 at 4:47 PM, Tres Seaver wrote: > >> > Basically all the internal strings are textish, so we're left with: >> >> What do you mean by "internal"? Anything in the headers or the

Re: [Web-SIG] WSGI for Python 3

which converted those bytes to strings on my behalf. > Making it easy to write "raw" middleware or applications without using > such a library doesn't seem as compelling a goal as being able to easily > write one which allowed me direct control at the raw level. > What are th

Re: [Web-SIG] WSGI for Python 3

Do you mean that you > want application programmers to have them transparently decoded? If so, > we can make that the responsibility of the non-middleware framework / > application. > By internal I mean all the CGI variables that aren't representing HTTP, like SER

Re: [Web-SIG] WSGI for Python 3

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 think >> bytes will be

Re: [Web-SIG] WSGI for Python 3

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 values. I > > think

Re: [Web-SIG] WSGI for Python 3

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 matters, in that >

Re: [Web-SIG] WSGI for Python 3

atin1 and get something reasonable. It's not very attractive to me that we take something that is probably *not* Latin1, and may reasonably not be ASCII, and decode it as Latin1. -- Ian Bicking | http://blog.ianbicking.org ___ Web-SIG mailing

Re: [Web-SIG] WSGI for Python 3

On Wed, Jul 14, 2010 at 12:04 AM, Graham Dumpleton < graham.dumple...@gmail.com> 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

[Web-SIG] WSGI for Python 3

;s some other topics, like chunked responses, unknown request body lengths, start_response, and maybe some other things, but these aren't Python 3 issues, they are just... generic issues. app_iter.close() might be worth thinking about given new iterator semantics introduced since WSGI was written.

Re: [Web-SIG] Emulating req.write() in WSGI

pages if the response isn't slow. And then there's really cheap tricks, like: Submit -- Ian Bicking | http://blog.ianbicking.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail

Re: [Web-SIG] http://wiki.python.org/moin/WebFrameworks

t; could try to contact the authors and ask about > what they think. > > -- Aaron Watters > > === > BTW, I think "Release early, release often" is nonsense > because it means you are probably releasing > something buggy and unstable which will just alien

Re: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec

bove what >> the Content-Length response header defines if supplied. >> >> This is already required by HTTP. If the WSGI gateway doesn't make this >> happen somehow, it's generating invalid HTTP and that's a bug. Okay to >> clarify in the spec to ensure peo

Re: [Web-SIG] Future of WSGI

andled. I still don't entirely understand the use case underlying that. But anyway, that's some of the motivation. start_response is still useful for retrofitting support for frameworks from time to time, but all the modern frameworks work differently these days making start_response se

Re: [Web-SIG] Future of WSGI

ickery on the part of frameworks. It's a common gateway between servers and frameworks, and can be used as a gateway between middleware and applications. And it's really fairly common for middleware to use the raw dictionary without any object involv

Re: [Web-SIG] Future of WSGI

On Tue, Nov 24, 2009 at 3:50 PM, Malthe Borch wrote: > 2009/11/24 Ian Bicking : > > You mean specifically environ['wsgi.input'] ? While the file-like > interface > > is difficult, other possible interfaces aren't so great either. As to > > putting the r

Re: [Web-SIG] Future of WSGI

he problem is? Or are you just concerned that people put arbitrary things in the environ? There's far too many important use cases that are satisfied by the extensible nature of the environ to give it up just because some people believe it is overused. -- Ian Bicking |

Re: [Web-SIG] Future of WSGI

ither in 1.1 or 2.0. > I'm not aware of any problems with representing the request with a dictionary. Can you give examples? -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Web-SIG mailing list Web-SIG@p

Re: [Web-SIG] Future of WSGI

le makes things easier. > > \malthe > > [1] http://bitbucket.org/ianb/wsgi-peps/src/tip/pep-0333.txt > [2] http://mockit.blogspot.com/2009/11/dont-look-back-in-anger.html > > ___ > Web-SIG mailing list > Web-SIG@python.org >

[Web-SIG] WebOb API

s are not easily separated, and it would require too much code duplication). (Incidentally WebOb is now on bitbucket: http://bitbucket.org/ianb/webob/) -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Web-SIG maili

Re: [Web-SIG] Getting back to WSGI grass roots.

won't *see* that they are thinking about the same thing. So just framing the question well is an important and difficult task. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Web-SIG mailing list Web-SI

Re: [Web-SIG] Converting REQUEST_URI to wsgi.script_name/wsgi.path_info

that those values are in any way related, and when that is the case it is appropriate to fix it up at the WSGI stage (not necessarily in the WSGI adapter itself). On Mon, Sep 28, 2009 at 2:34 AM, Graham Dumpleton < graham.dumple...@gmail.com> wrote: > 2009/9/28 Ian Bicking : > >

[Web-SIG] Converting REQUEST_URI to wsgi.script_name/wsgi.path_info

) Admittedly the tests are not very complete, I just wasn't feeling creative about test cases. In terms of performance this avoids being entirely brute force, but feels kind of complex. I'm betting there's an entirely different approach which is faster. But whatever. -- Ian B

Re: [Web-SIG] Proposal to remove SCRIPT_NAME/PATH_INFO

ould be a tuple; but at least WebOb doesn't allow iterators, only str/unicode. (You can give an iterator, but you need to do it with an app_iter keyword argument.) I don't know what Werkzeug or other frameworks allow. > > In general I think doing too many changes at once is har

[Web-SIG] Proposal to remove SCRIPT_NAME/PATH_INFO

ifically, tricks like the latin1 transcoding won't work in Python 2, but will in Python 3. Is this weird? Or just something you have to think about when using the two Python versions? What happens if you give unicode text in the response headers that cannot be encoded as Latin1? Should some

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

On Tue, Sep 22, 2009 at 3:16 AM, Armin Ronacher wrote: > Hi, > > Ian Bicking schrieb: > > Request headers, which you didn't split out... those I'm not sure. I'd > > *like* them to be native. But damn, I'm just not sure quite how. > > surrogatee

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

s can be Latin1. And you can represent arbitrary bytes that way. So if you want to send crazy stuff to the browser, you can do it that way. And if you want to stick to plain ASCII then that's easy enough as well. So... native? str or unicode? I'm not sure specifically for this one.

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

had to make up a name, but I agree with your suggestion for wsgi.X (we already have wsgi.url_scheme, after all). -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http:/

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

get the information from REQUEST_URI the hard way, once at the gateway level. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

ated by a real /.) If we do that, then the only really tricky thing left is HTTP_COOKIE, and since the Cookie header is a mess then HTTP_COOKIE will be a mess and we just have to figure out a hacky way to deal with that. Maybe surrogateescape, but probably just Latin1 woul

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

awkward interface to the request body. But I think resolving that is harder than start_response, in particular because there's no clear solution. Maybe at least switching to a file interface would be better. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker

Re: [Web-SIG] Unicode in Python 3

I can't read all this thread carefully, too much stuff. I will note however that people are STILL ignoring surrogateescape (http://www.python.org/dev/peps/pep-0383/). This is like the third or fourth time I've brought it up. It was added to Python 3.1 for some of the exact issues we are encounte

Re: [Web-SIG] Sketching a WSGI 2-to-1 adapter with greenlets

On Fri, Sep 18, 2009 at 7:09 PM, Armin Ronacher wrote: > Ian Bicking schrieb: >> What's wrong with this simpler approach to the conversion? > It buffers, you can no longer do this: > >   request.write('processing data') >   request.flush() >

Re: [Web-SIG] Sketching a WSGI 2-to-1 adapter with greenlets

assert status_headers if written: app_iter = itertools.chain(written, app_iter) return status_headers[0], status_headers[1], app_iter What's wrong with this simpler approach to the conversion? -- Ian Bicking | http://blog.ianbicking.org | ht

Re: [Web-SIG] String Types in WSGI [Graham's WSGI for py3]

ons are underspecified. I also think on Web-SIG we are approaching this with more robust and general applications in mind than for Jack and Rack -- for instance, I would like WSGI to be a reasonable basis for an HTTP proxy, where you can't enforce UTF8-everywhere. If all we wanted for WSGI was to b

Re: [Web-SIG] WSGI 1 Changes [ianb's and my changes]

discuss -- I think we'll just be more constructive if we stick to concrete changes to the PEP so we can easily implement what we all agree on. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Web-SIG mailing l

Re: [Web-SIG] WSGI and async Servers

n async context -- but that's fine too). -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python

Re: [Web-SIG] WSGI 2

On Tue, Aug 11, 2009 at 11:58 PM, Graham Dumpleton < graham.dumple...@gmail.com> wrote: > 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 &g

Re: [Web-SIG] WSGI 2

8859-1 is a reasonable fallback in this case, as it can be used to kind of reconstruct the original request path (the surrogateescape or whatever it is called would serve the same purpose, but is only available in Python 3). -- Ian Bicking | http://blog.ianbicking.org | http://topplabs

Re: [Web-SIG] WSGI 2

CAPS keys. You can put ints or unicode or whatever in other variables. (Probably this doesn't make things any easier for mod_wsgi, though; at least for this example) -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___

Re: [Web-SIG] PEP 333 and gzipping of responses

ioned is allowed. Clearly "Content-Encoding" and "Transfer-Encoding" are different strings. And, as you mention, the normal thing that people currently do is use Content-Encoding anyway, so since people aren't using Transfer-Encoding, why is this controversial? There are s

Re: [Web-SIG] WSGI 2

On Mon, Aug 3, 2009 at 11:28 PM, Graham Dumpleton wrote: >> Mainly I'm wondering, what should the server do in the event they receive a >> byte string which is not valid UTF-8?  (Latin-1 doesn't have this problem, >> since there's no such thing as an invalid Latin-1 string, at least not at >> the e

[Web-SIG] WSGI 2

ere anyone willing to make the revisions? -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailm

[Web-SIG] Developer authentication spec

developers. Since I wrote the spec I've written up an implementation: https://svn.openplans.org/svn/DevAuth/trunk Last time I brought this up there wasn't any response, but I'm hoping it'll... I dunno, make more sense or seem more interesting now. -- Ian Bicking | http:/

Re: [Web-SIG] Python 3.0 and WSGI 1.0.

On Tue, May 5, 2009 at 10:14 PM, Graham Dumpleton < graham.dumple...@gmail.com> wrote: > 2009/5/6 Ian Bicking : > > Philip Jenvey brought this to my attention: > > > > http://www.python.org/dev/peps/pep-0383/ > > > > It's a UTF8 encoding and decoding

Re: [Web-SIG] Python 3.0 and WSGI 1.0.

es exactly like WSGI. -- Ian Bicking | http://blog.ianbicking.org ___ 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

Re: [Web-SIG] FW: Closing #63: RFC2047 encoded words

stracts away the awkwardness of the WSGI call signature, and also does header parsing. -- Ian Bicking | http://blog.ianbicking.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org

Re: [Web-SIG] Reverse Proxy & HTTPS

scribe: > http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com > > ___ > Web-SIG mailing listweb-...@python.org > Web SIG: http://www.python.org/sigs/web-sig > > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/randy%40rcs-comp.com >

Re: [Web-SIG] Python 3.0 and WSGI 1.0.

bytes unless it cared. This might be fine, except it is hard. You can't just take arbitrary bytes and do script_name.decode('utf8'), and then when you realize you had it wrong do script_name.encode('utf8').decode('latin1'). -- Ian Bicking | http://blog.ianbi

Re: [Web-SIG] thoughts on an iterator

the strings are in memory the consumer really isn't any better off reading a smaller chunk than what is available. This also means I can stop making up entirely random chunk sizes in applications. Applications have no real information to inform this chunking. If the string is alread

Re: [Web-SIG] how to test hunging socket ?

I use webob... > If your app isn't threadsafe, you should use a multiprocess server. mod_wsgi has options for this, and flup has forking options (you'd use flup behind Apache or another server). -- Ian Bicking | http://blog.ianbicking.org __

Re: [Web-SIG] how to test hunging socket ?

et > Informaticien Indépendant > > ___ > 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/ianb%40colorstudy.com > -- Ian

Re: [Web-SIG] wsgiref.validate allows wsgi.input.read() with no argument

;t do environ['wsgi.input'].read(). The validator does not test for that case, that is what I am pointing out. The validator allows read() to be called with no argument. Ah, sorry, I wasn't paying attention... okay, then yes, I agree -- the validator should be more restrictive.

Re: [Web-SIG] wsgiref.validate allows wsgi.input.read() with no argument

a broken application on some servers. This is not an uncommon problem. Therefore the validator tests for this case; if you want an application that actually works consistently, you shouldn't do environ['wsgi.input'].read(). -- Ian Bicking : i...@colorstudy.com : http://blog.ianb

Re: [Web-SIG] Revising environ['wsgi.input'].readline in the WSGI specification

Manlio Perillo wrote: Ian Bicking ha scritto: [...] We need to propose a change to the WSGI specification. I propose, in "Input and Error Streams" (http://www.python.org/dev/peps/pep-0333/#input-and-error-streams) we change it to have "readline(hint)" and expand Note 3

Re: [Web-SIG] Revising environ['wsgi.input'].readline in the WSGI specification

Mark Ramm wrote: On Mon, Nov 17, 2008 at 12:55 PM, Andrew Clover <[EMAIL PROTECTED]> wrote: Ian Bicking wrote: To resolve this, let's just not pass it over this time? Totally agreed. What exactly needs to happen next? We need to propose a change to the WSGI specification. I

  1   2   3   4   5   6   >