Re: [Web-SIG] Inviting feedback on my proposed "ASGI" spec
On Thu, 10 Mar 2016, Andrew Godwin wrote: I think you're right, and I've just been stubbornly trying to use a dict as it's slightly "nicer". I honestly considered making both sides dict and cookies the separate thing as they're the only special case, but I suspect that multiple headers are one of those things that might turn out to be useful for some broken client/new feature someday. It sounds like you consider multiple headers of the same name in request and response as some kind of bug or fault. It's not it is perfectly legit and something I want to be able to do in my webbby frameworks. Vary is the main one. I know that I can join on ',' in a single header when it is represented in a dict but "meh". I totally agree that dicts are much nicer to work with, so I'm not sure what the ideal solution is, but I just wanted to raise that point about multiple headers. As you were. Carry on. etc. -- Chris Dent http://burningchrome.com/ [...] ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest
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
`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 access the raw un-decoded request URI. This is
so I can reconstruct a realistic `PATH_INFO` that has not been
subjected to destructive handling by the server (e.g. apache
messing with `%2F`) before continuing on to a route dispatcher.
This is already available in some servers by way of the REQUEST_URI value.
Yes, and in others (as mentioned by Benoit) as RAW_URI. One
("consistent") way would be better.
[Lots of good information about the challenges associated with using
that information to do anything useful, deleted.]
What I've done in one app is this:
https://github.com/tiddlyweb/tiddlyweb/blob/cc6b67d2855ea4d8d908f1a3e58db0dce7e8d138/tiddlyweb/web/serve.py#L119
Despite the fact that that is not strictly correct, it does mostly work
for the situation described in the comment and the context of that
app. One of the things I want from a light rev of WSGI is not to have
to jump through those hoops.
It may be that's not feasible but I reckon we're at the wishing
stage of the discussion.
--
Chris Dent http://burningchrome.com/
[...]
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] resources for porting wsgi apps from python 2 to 3
On Tue, 2 Oct 2012, And Clover wrote: [a bunch of useful stuff] Thanks, that was nicely cogent and thus very useful. I've got a first working version: https://github.com/cdent/python3-wsgi-intercept I need to codify some things in tests a bit more, and there's an issue with https request and http.client, but I'm close. -- Chris Dent http://burningchrome.com/ [...] ___ 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
[Web-SIG] resources for porting wsgi apps from python 2 to 3
I was at pyconuk over the weekend and came away from that all refreshed and wanting to hack. That combined with the recent release of Python 3.3 had me deciding it was time to start porting TiddlyWeb[1] to Python3. I'm having progress along some lines and a bit of a mess along others. The major holdback right now are dependencies which are not yet ported, which I'd like to port as well, but proving hard to port because they have test dependencies which themselves are not yet ported. A medium sized issue is related to how WSGI is supposed to behave in Python3. TiddlyWeb is its own framework and doesn't use webob or werkzeug, etc. It does dispatch with selector, but other than that processes handling headers and request body as it gets them from the server. For tests it uses wsgi-intercept[2] to simulate a web server. I've volunteered to port that (having already done some minor work on it in the past) so need to get clear and the disposition of bytes or strings in headers and bodies of both requests and responses. I have a few questions that I'm hoping people here will help me answer, or at least point me in the right direction. I'll be happy to summarize the results after the discussion has tailed off.[3] I've looked over pep and don't some other reading, but I don't feel fully confident. The question is mostly around what part of the stack should be uptight. In the below when I say bytes and str I mean the Python 3 types. * Should wsgi-intercept (which fakes a server) when giving request info to a fake app: * Use bytes or str for environ keys? * Use bytes or str for environ values? * Are all environ values created equal or would, for example, QUERY_STRING's value (prior to any parameter to decoding) be handled differently from HTTP_COOKIE * If str, I see that ISO-8859-1 is the assumed encoding. How much hurt occurs in the world if I just assume utf-8 when decoding to str[4]? * When wsgi-intercept is accepting data from the wsgi app: * Should start_response only accept bytes (and error if not), or should it also accept str and encode appropriately? To put it another way: be liberal or srict? If encoding, which encoding? * Should the returned iterable be rejected or encoded if not bytes? What have I forgotten? Thanks for any input, comments, etc. The thing at [3] has a few more details on some of the related issues and pieces of the puzzle. [1] http://tiddlyweb.com/ https://github.com/tiddlyweb/tiddlyweb [2] http://code.google.com/p/wsgi-intercept/ [3] I've started keeping notes on this project at http://tiddlyweb3.tiddlyspace.com/ [4] Which is what it should have been all along? -- Chris Dent http://peermore.com/ -- Chris Dent http://burningchrome.com/ [...] ___ 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] Server-side async API implementation sketches
On Sun, 9 Jan 2011, Alice Bevan–McGregor wrote: On 2011-01-09 09:03:38 -0800, P.J. Eby said: Hm. I'm not sure if I like that. The typical app developer really shouldn't be yielding multiple body strings in the first place. Wait; what? So you want the app developer to load a 40MB talkcast MP3 into memory before sending it? My reaction too. I've read this elsewhere on this list too, in other topics. A general statement that the correct way to make an efficient WSGI (1) app is to return just one body string. This runs contrary to everything I've ever understood about making web apps that appear performant to the user: get the first byte out to the browser as soon as possible. This came up in discussions of wanting to have a cascading series of generators (to save memory and improve responsiveness): store generates data, serializers generates strings, handler generates (sends out in chunks) the web page from those strings. So, this is me saying: I'm in favor of a post-wsgi1 world where apps are encouraged to be generators. To me they are just as useful in sync and async contexts. -- Chris Dent http://burningchrome.com/ [...]___ 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 Goals
On Thu, 6 Jan 2011, Alice Bevan–McGregor wrote: :: Clear separation of narrative from rules to be followed. This allows developers of both servers and applications to easily run through a confomance check list. +1 :: Isolation of examples and rationale to improve readability of the core rulesets. +1 :: Clarification of often mis-interpreted rules from PEP 333 (and those carried over in ). +1 :: Elimination of unintentional non-conformance, esp. re: cgi.FieldStorage. +1 :: Massive simplification of call flow. Replacing start_response with a returned 3-tuple immensely simplifies the task of middleware that needs to capture HTTP status or manipulate (or even examine) response headers. [1] +1 I was initially resistant to this one in a we fear change kind of way, but I've since recognized that a) I was thinking about it mostly in terms of existing code I have that would need to be changed b) it _is_ more pythonic. :: Reduction of re-implementation / NIH syndrome by incorporating the most common (1%) of features most often relegated to middleware or functional helpers. Unicode decoding of a small handful of values (CGI values that pull from the request URI) is the biggest example. [2, 3] 0 (as in unsure, need to be convinced, etc) The zero here is in large part because this particular goal could cover a large number of things from standardized query string processing (maybe a good idea) to filters (which I've already expressed reservations about). So this goal seems like it ought to be several separate goals. :: Cross-compatibility considerations. The definition and use of native strings vs. byte strings is the biggest example of this in the rewrite. +1 :: Making optional (and thus rarely-implemented) features non-optional. E.g. server support for HTTP/1.1 with clarifications for interfacing applications to 1.1 servers. Thus pipelining, chunked encoding, et. al. as per the HTTP 1.1 RFC. 0 The other option (than non-optional) for optional things is to remove them. I think working from a list of goals is an excellent way to make some headway. -- Chris Dent http://burningchrome.com/ [...]___ 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 / WSGI 2 Async
On Wed, 5 Jan 2011, Alice Bevan–McGregor wrote: This should give a fairly comprehensive explanation of the rationale behind some decisions in the rewrite; a version of these conversations (in narrative style vs. discussion) will be added to the rewrite Real Soon Now™ under the Rationale section. Thanks for this. I've been trying to follow along with this conversation as an interested WSGI app developer and admit that much of the thrust of things is getting lost in the details and people's tendency to overquote. One thing that would be useful is if, when you post, Alice, you could give the URL of whatever and wherever your current draft is. That out of the way some comments: For me WSGI is a programmers' aid used to encourage ecapsulation and separation of concerns in web applications I develop. After that there's a bit about reuability and portability, but the structure of the apps/middleware themselves are the most important concerns for me. I don't use frameworks, or webob or any of that stuff. I just cook up callables that take environ and start_response. I don't want my awareness of the basics of HTTP abstracted away, because I want to make sure that my apps behave well. Plain WSGI is a good thing, for me, because it means that my applications are a) very webby (in the stateless HTTP sense) and b) very testable. This is all works because WSGI is very simple, so my tendency is to be resistant to ideas which appear to add complexity. --- 444 vs. GothAlice: Async, filters, no server-level buffering, native string usage, the definition of byte string as the format returned by socket read (which, on Java, is unicode!), and the allowance for returned data to be Latin1 Unicode. \ All of this together will allow a '''def hello(environ): return 200 OK, [], [Hello world!]''' example application to work across Python versions without modification (or use of b prefix) On async: I agree with some others who have suggested that maybe async should be its own thing, rather than integrated into a WSGI2. A server could choose to be WSGI2 compliant or AWSGI compliant, or both. Having spent some time messing about with node.js recently, I can say that the coding style for happy little async apps is great fun, but actually not what I really want to be doing in my run-of-the-mill as- RESTful-as-possible web apps. This might make me a bit of a dinosaur. Or a grape. That said I can understand why an app author might like to be able to read or write in an async way, and being able to shelf an app to wait around for the next cycle would be a good thing. I just don't want efforts to make that possible to make writing a boring wsgi thing more annoying. On filters: I can't get my head around filters yet. They sound like a different way to do middleware, with a justification of something along the lines of I don't like middleware for filtering. I'd like to be (directly) pointed at a more robust justification. I suspect you have already pointed at such a thing, but it is lost in the sands of time... Filters seem like something that could be added via a standardized piece of middleware, rather than being part of the spec. I like minimal specs. GothAlice: Latin1 = \u → \u00FF — it's one of the only formats that can be decoded while preserving raw bytes, and if another encoding is needed, transcode safely. \ Effectively requiring Latin1 for unicode output ensures single byte conformance on the data. \ If an application needs to return UTF-8, for example, it can return an encoded UTF-8 bytestream, which will be passed right through, There's a rule of thumb about constraints. If you must constrain, do none, one or all, never some. Ah, here it is: http://en.wikipedia.org/wiki/Zero_One_Infinity Does that apply here? It seems you either allow unicode strings or you don't, not a certain subsection. My own personal method is: textual apps _always_ return unicode producing iterators and a piece of (required, thus not offical by some people's biases) middleware turns it into UTF-8 on the way out. I've naively never understood why you want do anything else? My general rule is unicode inside, UTF-8 at the boundaries. That's all I got so far. I applaud you for taking on this challenge. It's work that needs to be done. I hope to be able to comment more and make a close reading of the various documents, but time is tough sometimes. I'll do what I can as I can. Thanks. -- Chris Dent http://burningchrome.com/ [...]___ 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 Sun, 19 Sep 2010, Ian Bicking wrote: On Sun, Sep 19, 2010 at 11:32 AM, Chris McDonough chr...@plope.com wrote: I propose to write in the PEP that a middleware should provide an app attribute to get the wrapped application or middleware. It seems to be the most common name used out there. We can't really mandate this because middleware is not required to be an instance. It can be a function. We could suggest it, and suggest the attribute name. Composites, lazy loading middleware, or a bunch of other situations can break it... but it's nice for introspection tools to at least be able to attempt to run down the chain. Middleware is almost always a closure if it's a function, I believe, so you could still do: If the goal here is to write a spec, then I would prefer that spec say what must be done and what must not be done, not what may be done, could be done or is suggested as perhaps a best practice. Those sorts of things belong in communication that is out of band of the spec. -- Chris Dent http://burningchrome.com/ [...] ___ 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, 17 Sep 2010, Ionel Maries Cristian wrote: I feel this spec puts too much burden on applications - having to process all those byte strings and even having to add Content-Length even for naive buffered-body apps. The Content-Length requirement is a big killer for me. I'm usually generating content in apps, rather deep in a stack of middleware-like pieces that may or may not be looking at or modifying that content. I don't want to a) have to unwind my generators at each level b) reset the content-length here there and everywhere. It could be I'm doing it completely wrong, but it works rather nicely. -- Chris Dent http://burningchrome.com/ [...] ___ 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 Thu, 16 Sep 2010, jason kirtland wrote: The 'pegboard' middleware composes a result out of an arbitrary graph of WSGI apps, with one request visiting many applications. The graph can be built at runtime in application code, so it would be very difficult to report all of the '.app's applicable for a given environ until after the request. Also, it is quite reasonable in practice to have middleware both in front of such a composer and also in the stacks of the apps it composes. The general rule we can extract from this is that we don't want the spec to limit what is possible for the sake of making fairly arbitrary things that only some people (think they?) need and can be satisfied using the more fundamental units already present in the design. I can see that applying here, thus we don't want to enforce some kind of app method or attribute as that could be costly for assembling flexible groups of apps (in the same app). On the other end of that same principle, I'm not sure I can see much justification in (paraphrase) let's make the return signature be the same as the signature of some constructors at use out there in the wild. One of the best things about WSGI, that I hope does not get lost in Web3 (thanks for moving things forward, by the way), is that in its most basic use it is almost entirely about (simple) data structure and (simple) data flow and not about methods, objects, magical attributes and other flim flammery. In other words it is good that the units are basic and fundamental. -- Chris Dent http://burningchrome.com/ [...] ___ 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, 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 this makes sense. The thing which is assembling the WSGI environment should do bytes and things further down the stack can deal with it as they like. This aligns well with how I like to think about such stuff: bytes on the outside, unicode on the inside. Given that app and frameworks developers can throw whatever keys they like back into the environment, they can cope as they like.[1] What would be horrible is if there need to be multiple coping strategies. Better to be able to say, Oh it doesn't work? Try this way to cope: remember it is bytes. However, unless I'm misreading the thread, the bytes issue isn't really the bone of contention. People seem okay with bytes as long as specifc points of pain are addressed, such as: * What's my PATH_INFO and SCRIPT_NAME? * This server, which hosts, but is not, the WSGI environment builder doesn't play well with this model. * Some others I can't remember now. It seems then that perhaps a way forward is to say: Okay, it's gonna be bytes. Now, given that, how do we deal with these other issues, which perhaps can be recast and encapsulated to be considered orthogonal to the bytes/not-bytes debate. Because we _know_ that any choice is going to come with costs, but as things have dragged on, the lack of choice thus far is starting to have as much of a cost as the costs that are wanting to be resolved. [1] I not expecting or hoping for porting/migrating to Python 3 to be simple/automatic/easy, but perhaps I'm cruel. -- Chris Dent http://burningchrome.com/~cdent/ [...] ___ 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
