Re: [Web-SIG] How to make REMOTE_USER variable private across WSGI middlewares?
I think this is not the best mailing list to ask a question like this. You are probably better served to ask on Stack Overflow or some other place with more activity. For what it's worth, I also think you might misunderstand how WSGI works. I believe the environment object is supposed to exist in a request context. I'm assuming you only need one user per request, so simply filling in the value of REMOTE_USER seems to me like it should work. However, I haven't looked at your code or thought long about the problem, it's just an off-handed observation based on your description below. *Randy Syring* Husband | Father | Redeemed Sinner /"For what does it profit a man to gain the whole world and forfeit his soul?" (Mark 8:36 ESV)/ On 10/11/2016 06:47 PM, Etienne Robillard wrote: Here's the source code: https://bitbucket.org/tkadm30/django-hotsauce/src/6a862e22e045cb10a84f3b08e4c237ed592ecec7/lib/notmm/controllers/wsgi.pyx A live demo is here: http://www.isotopesoftware.ca/ The problem is in the init_request method. The current implementation uses threading.local. I have no idea how to make the WSGI environ object a thread-local in case the remote user has been logged in. Any input would be greatly appreciated. Regards, Etienne Le 2016-10-10 à 10:30, Etienne Robillard a écrit : Hi, I'm attempting to develop a OAuth 2.0 authentication middleware which sets REMOTE_USER variable into the WSGI environ object, however I'm unable to make this variable unique for the logged user. Is it recommended to use threading.local or gevent to make the WSGI environment persisting on a per-request basis ? What others options can you advise to make private request data not accessible in WSGI ? Thanks in advance, Etienne ___ 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 for HTTP/2.0 ?
On 09/20/2014 02:31 AM, Graham Dumpleton wrote: The problem with trying to overhaul WSGI is that if it is done in an open forum like the Web-SIG it will die of a thousand cuts, as past efforts to update it in even minor ways have suffered. The only way that WSGI itself will ever see an overhaul is through the strong willed determination of a few people off list, out of sight, to allow it it to be fully fleshed out, with input coming from direct consultation with and review by other related parties who have a vested interested or significant experience in the area. I may be up for such an off list effort, but be warned I may want to run roughshod over it and exert quite a lot of influence over the process and outcome. I'm no one important in the Python world, but, FWIW, I agree with you. I've followed your work over the years and believe you have a penchant for details and accuracy as evidenced by your comments here on the list and your work on modwsgi and wrapt. I'd be very interested in seeing what you could come up with. IMO, if you are up for it, you should feel free to grab a few people that you would like to work with and hammer out a PEP (or it's precursor). Then, let the PEP process work as it's intended to. Hopefully, this method results in a trend towards more concrete and specific arguments and less likely to die of a thousand cuts. I'm going to refer this group as the draft team. On 20 September 2014 19:14, Benoit Chesneau bchesn...@gmail.com wrote: I would prefer to have this work being done transparently. If we do it rationally it could work imo. I don't think anyone is arguing against transparency. But momentum matters and, in the history of changes to the WSGI spec, momentum has died pretty easily even when there were clearly changes that needed to be made. If Graham, or anyone else for that matter, has the gumption to go at this thing hard and get something written down, I think that that should be encouraged. Even if the initial phases of that processes are behind closed doors, transparency will come eventually and there will be opportunity for comment. But if you make the process too transparent too early, the energy used to keep up with everyone and all the different needs can take away from doing the actual work of defining the spec. got an idea. What about having a page collecting feedback from anyone in the python community about this topic. So we can have true data from different perspectives: developer, library/framework author, server author. I'm OK to collect the data from it and make a summary of it once it's done. This seems reasonable. That way, interested parties could get their comments on record without the draft team needing to feel like that have to satisfy or even have a discussion about every comment. The form it could take should be discussed first but imo that a good way to engage the community. What do you think? I'd suggest a wsgi comments github repo. Workflow: * Submit a document to the repo with your comments on the future version of WSGI o use any readable format you want (Markdown, RST, plain text, etc.). o include name, contact information, background. Make sure to give enough info about your background so the draft team has some context for the proposals and comments you are making. * Any desired discussion by interested parties can be had on the pull request page (or here I guess, but that might be noisy) * The author can update pull request if desired based on discussion * pull requests are automatically accepted after some time period (1 week?) of no further comments o the delay in acceptance is to give time for discussion and updates to the PR o a PR merge does not indicate that the idea will be accepted into the WSGI PEP, it's just being merged into the comments repo * an individual should only update their own document, no PRs against someone else's document. o comments/discussions should go on the PR Just my $0.02. *Randy Syring* Husband | Father | Redeemed Sinner /For what does it profit a man to gain the whole world and forfeit his soul? (Mark 8:36 ESV)/ ___ 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] SERVER_PORT and Unix sockets
I'm sure you've read this: http://www.python.org/dev/peps/pep-0333/#environ-variables The following variables must be present, unless their value would be an empty string, in which case they may be omitted, except as otherwise noted below. ...snip... SERVER_NAME, SERVER_PORT When combined with SCRIPT_NAME and PATH_INFO, these variables can be used to complete the URL. Note, however, that HTTP_HOST, if present, should be used in preference to SERVER_NAME for reconstructing the request URL. See the URL Reconstruction section below for more detail. SERVER_NAME and SERVER_PORT *can never be empty strings, and so are always required.* So, it sounds to me like the spec doesn't take unix sockets into consideration, which makes sense. Either way, if you omit, or set the value to an empty string, you are going to be violating the spec. FWIW, if it was me, I'd follow suit with what the other servers are doing. - Randy Syring Intelicom |Level 12 http://inteli-com.com/index.html#level12 Direct: 502-276-0459 Office: 502-212-9913 For the wages of sin is death, but the free gift of God is eternal life in Christ Jesus our Lord (Rom 6:23) On 01/02/2012 09:59 AM, Jonas H. wrote: Hello everyone! What is SERVER_PORT supposed to be set to if the WSGI server is only bound to a Unix socket? Some major Web servers (Gunicorn, CherryPy) set it to the empty string. Intuitively I'd rather not set it at all. What do you guys recommend? btw, www.wsgi.org != wsgi.org. That's very confusing. Jonas ___ 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/rsyring%40gmail.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] A Python Web Application Package and Format
On 04/14/2011 11:45 AM, Eric Larson wrote: ...regarding apache/nginx config if necessary, but basing that on the expectation there is a single script is a better approach than presuming a config can provide enough information to eventually create some script that apache/nginx/etc. might need to use. Just wondering if Windows/IIS is being kept in mind as this discussion is going on. I am having a hard time conceptualizing the things being discussed, so can't really tell myself. Thanks. -- Randy Syring Intelicom Direct: 502-276-0459 Office: 502-212-9913 For the wages of sin is death, but the free gift of God is eternal life in Christ Jesus our Lord (Rom 6:23) ___ 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] Extracting web data
Also, if you are familiar with jQuery selector syntax, pyquery is very helpful! -- Randy Syring Intelicom Direct: 502-276-0459 Office: 502-212-9913 For the wages of sin is death, but the free gift of God is eternal life in Christ Jesus our Lord (Rom 6:23) On 02/20/2011 11:21 PM, Deb Midya wrote: Hi Python web-sig users, Thanks in advance and I am new to web-sig. I am using Python 2.6 on Windows XP. May I request you to assist me for the following please. I like to extract web data from the site (http://finance.yahoo.com http://finance.yahoo.com/, for example). The data may include Historical Prices, Key Statistics, News Info, Headlines, etc. for a list of codes (such WOW, these are codes for company Ids). I am trying to automate the extraction of data. Is there any Python module or any assistance please? Once again, thank you very much for the time you have given. Regards, Deb ___ 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/randy%40rcs-comp.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)
Thanks to Chris M. and Armin for moving forward with a PEP! Armin Ronacher wrote: Hi, On 9/16/10 1:23 PM, Dirkjan Ochtman wrote: I find the order of the application return arguments really annoying, could it just be status, headers, body? Mirrors the actual structure of the request, which is easier to remember IMO. The motivation is that you can pass that to constructors of response objects already in place. response_tuple = response.get_response_tuple() response = Response(*response_tuple) chris.d...@gmail.com wrote: 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. FWIW, I am with Dirkjan and Chris on this...the most logical ordering for a response tuple is: status, headers, body Trying to conform the spec to existing frameworks doesn't seem like the best approach in this case. -- Randy Syring Intelicom 502-644-4776 Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 chris.d...@gmail.com wrote: 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. ___ 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)
Ty Sarna wrote: On Sep 16, 2010, at 2:55 PM, Massimo Di Pierro wrote: My experience in various communities suggests that naming the new totally-bw-incompat thing the same as the old thing weakens both the new thing and the old thing, I share the same experience. Interesting. Do you feel that Python 3.x should have been named something other than Python? I think that would rather have weakened both 3.x and 2.x by suggesting a fork, placing the two in competition, when the goal was to have one supersede the other, as is also the case here. FWIW, I agree on this point. WSGI2 seems better than WEB3. IMO, its OK to put a disclaimer at the top of the spec that states they are different specs and entirely backwards incompatible. If there is consensus to more away from WSGI, then I think a name other than WEB3 is in order. Its just too generic. -- Randy Syring Intelicom 502-644-4776 Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 ___ 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] High Performance solutions are needed to do things like urlretrieve
Do you have problems downloading said zip file with something like wget? This sounds, without more info, like a network connection issue more than anything else. Not saying thats the problem, just wondering if you have checked that possibility on your end. -- Randy Syring Intelicom 502-644-4776 Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 David Shi wrote: urlretrieve works fine. However, when file size get very large. It goes on forever, and even fails. For instance, one of download .zip file is of 363,096KB. Particularly, when trying to get, with urlretrieve, a zipped folder of a very large size, it could take up to 20 to 30 minutes. Often it fails, never any problem with smaller folders. Any solution for this? Regards. David ___ 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/randy%40rcs-comp.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] SQLAlchemy Queries HTML Data Grid
Aaron,
Sorry, I must not really have explained clearly. This isn't an
abstraction layer, but more like a UI component or widgit that
facilities basic reporting. Look at these pages:
http://www.redmine.org/issues
http://trac.edgewall.org/query
Both pages have a similar structure:
* UI Controls
o filtering
o grouping
o column selection
o sorting
* Paged/Sortable Recordset Display
The library would do the heavy lifting and allow any application using
SQLAlchemy to easily create such query/recordset interfaces to
underlying data.
You would need to:
* Instantiate the DataGrid class
* Create a base SQLAlchemy query to be used for the data
* Define the filter types associated with the columns (i.e.
TextFieldFilter, OptionsFilter('low','medium', 'high'),
DateSpanFilter, etc.)
* Limit sorting, grouping to appropriate columns
* choose which columns of the dataset to show by defaults
The library would then:
* parse GET/POST for filter/column/sort/page settings /or use defaults
* compose SQLALchemy query to satisfy the request
* execute the query and get the database results
* put results into an HTML table
* return the HTML form needed for the controls and the recordset
table including necessary CSS and JS
Obviously, the library should be easily customizable and the rendering
of HTML should be flexible. It should also be flexible enough to work
with the different WSGI libraries out there.
I hope that makes better sense. If you or anyone else is interested, I
can give you some code I have working from the pysapp project which does
some basic filtering, paging, and sorting. The API is awful, but I
think it might give you a better idea of what I am talking about.
--
Randy Syring
Intelicom
502-644-4776
Whether, then, you eat or drink or
whatever you do, do all to the glory
of God. 1 Cor 10:31
Aaron Watters wrote:
Thanks Randy, very interesting.
My initial reaction is that you are building a stack on top of a stack.
It's not clear to me what problem you want to solve
and your requirements are. It's possible that
you could find it easier to abstract directly on top of SQL or
alternatively
you could consider using another sort of data model like mongodb.
Building an abstraction on top of SQLAlchemy which hasn't even reached
1.0 strikes me as dubious.
Thanks again, -- Aaron Watters
--- On *Tue, 4/6/10, Randy Syring /rsyr...@inteli-com.com/* wrote:
From: Randy Syring rsyr...@inteli-com.com
Subject: [Web-SIG] SQLAlchemy Queries HTML Data Grid
To: web-sig@python.org
Date: Tuesday, April 6, 2010, 4:37 PM
I am planning on building a library that will facilitate creation
of custom queries and html display of resulting datasets from
SQLAlechemy queries. I have some basic work done here:
https://svn.rcslocal.com:8443/svn/pysmvt/pysapp/branches/0.1/pysapp/modules/datagrid/
But I don't like the API and I don't want the library to be
dependent on pysapp. Furthermore, I would like to have a more
verbose querying ability akin to Redmine:
http://www.redmine.org/projects/redmine/issues
Including:
* Filters
* Column Selection
* Grouping (multiple levels)
* Sorting (multiple columns)
* some kind of query saving/loading mechanism with a flexible
backend
I have done some basic table generation work here:
https://svn.rcslocal.com:8443/svn/pysmvt/pysdatagrid/trunk/
with the tests being the best place to get an idea of how it works:
https://svn.rcslocal.com:8443/svn/pysmvt/pysdatagrid/trunk/pysdatagrid/tests/test_render.py
Looking for comments, pointers to other projects, and/or possibly
interest in helping with a project like this. I am currently
working in SVN but will most likely move to hg/git if there are
others who are interested.
--
--
Randy Syring
Intelicom
502-644-4776
Whether, then, you eat or drink or
whatever you do, do all to the glory
of God. 1 Cor 10:31
-Inline Attachment Follows-
___
Web-SIG mailing list
Web-SIG@python.org /mc/compose?to=web-...@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/arw1961%40yahoo.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] SQLAlchemy Queries HTML Data Grid
It seems you want a sortable HTML table that talks to a back end query engine. I don't see why this needs to be specific to SQLAlchemy. Well...not just sorting though. Sorting, filtering, grouping, column selection, and paging. You are right that the backend does not need to be SQLAlchemy specific, but since that is what I use, that is what I was going to start with. Ideally, the library would be both sql framework and wsgi framework agnostic. The main point of the library would be to save the time/hassle in creating the HTML/CSS/JS for the query controls. -- Randy Syring Intelicom 502-644-4776 Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 ___ 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] SQLAlchemy Queries HTML Data Grid
I am planning on building a library that will facilitate creation of custom queries and html display of resulting datasets from SQLAlechemy queries. I have some basic work done here: https://svn.rcslocal.com:8443/svn/pysmvt/pysapp/branches/0.1/pysapp/modules/datagrid/ But I don't like the API and I don't want the library to be dependent on pysapp. Furthermore, I would like to have a more verbose querying ability akin to Redmine: http://www.redmine.org/projects/redmine/issues Including: * Filters * Column Selection * Grouping (multiple levels) * Sorting (multiple columns) * some kind of query saving/loading mechanism with a flexible backend I have done some basic table generation work here: https://svn.rcslocal.com:8443/svn/pysmvt/pysdatagrid/trunk/ with the tests being the best place to get an idea of how it works: https://svn.rcslocal.com:8443/svn/pysmvt/pysdatagrid/trunk/pysdatagrid/tests/test_render.py Looking for comments, pointers to other projects, and/or possibly interest in helping with a project like this. I am currently working in SVN but will most likely move to hg/git if there are others who are interested. -- -- Randy Syring Intelicom 502-644-4776 Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 ___ 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] Getting back to WSGI grass roots.
P.J. Eby wrote: I, for one, *really* appreciate the work you put into all of this, as I previously commented on your blog post. And I really hope you'll hang in there. Thanks for all your hard work. +...15 or so :) My +s may not count for much, but they go to many others as well. I have been amazed at some of the detail and thoughtfulness you are all putting into this discussion. Thank you all for your hard work. -- Randy Syring Intelicom 502-644-4776 Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 ___ 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] repoze.bfg web framework 1.0 released
Chris, Sounds interesting. Question: Does it support some kind of module/plugin architecture that will allow me to develop plug- in functionality across projects? What would be called in Django an app. For example, I would like to have a news, blog, and calendar module that I can plug into different applications. The goal is to have everything for the module contained in one subdirectory or package including any configuration, routing, templates, controllers, model, etc. So, something like this: /modules/news/... /modules/calendar/... /modules/blog/... Or: packages/ MyProj NewsComponent CalendarComponent BlogComponent I ended up writing my own framework because I needed this and didn't want to go with Django and Pylons didn't support it: http://groups.google.com/group/pylons-discuss/browse_thread/thread/14aef22ddb90347f But would love to be able to use something else that was more of a community effort. Thanks. -- -- Randy Syring RCS Computers Web Solutions 502-644-4776 http://www.rcs-comp.com Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 On Sun, Jul 5, 2009 at 8:47 PM, Chris McDonough chr...@plope.com wrote: Summary --- The first major release of the BFG web framework (aka repoze.bfg), version 1.0, is available. See http://bfg.repoze.org/ for general information about repoze.bfg. Details --- BFG is a Python web framework based on WSGI. It is inspired by Zope, Pylons, and Django. It makes use of a number of Zope technologies under the hood. BFG is developed as part of the more general Repoze project (http://repoze.org). It is released under the BSD-like license available from http://repoze.org/license.html . BFG version 1.0 represents one year of development effort. The first release of BFG, version 0.1, was made in July of 2008. Since then, roughly 80 pre-1.0 releases have been made. None of these pre-1.0 releases explicitly promised any backwards compatibility with any earlier release. Version 1.0, however, marks the first point at which the repoze.bfg API has been frozen. Future releases in the 1.X line guarantee API-level backward compatibility with 1.0. A backwards incompatibility with 1.0 at the API level in any future 1.X version will be considered a bug. More Details BFG contains moderate, incremental improvements to patterns found in earlier-generation web frameworks. It tries to make real-world web application development and deployment more fun, more predictable, and more productive. To this end, BFG has the the following features: - WSGI-based deployment: PasteDeploy and mod_wsgi compatible. - Runs under Python 2.4, 2.5, and 2.6. - Runs on UNIX, Windows, and Google App Engine. - Full documentation coverage: no feature or API is undocumented. - A comprehensive set of unit tests. The repoze.bfg package contains 11K lines of Python code. 8000 lines of that total line count is unit test code that tests the remaining 3000 lines. - Sparse resource utilization: BFG has a small memory footprint and doesn't waste any CPU cycles. - Doesn't have an unreasonable set of dependencies: easy_install -ing repoze.bfg over broadband takes less than a minute. - Quick startup: a typical BFG application starts up in about a second. - Offers extremely fast XML/HTML and text templating via Chameleon (http://chameleon.repoze.org/). - Persistence-agnostic: use SQLAlchemy, raw SQL, ZODB, CouchDB, filesystem files, LDAP, or anything else which suits a particular application's needs. - Provides a variety of starter project templates. Each template makes it possible to quickly start developing a BFG application using a particular application stack. - Offers URL-to-code mapping like Django or Pylons' *URL routing* or like Zope's *graph traversal*, or allows a combination of both routing and traversal. This helps make it feel familiar to both Zope and Pylons developers. - Offers debugging modes for common development error conditions (for example, when a view cannot be found, or when authorization is being inappropriately granted or denied). - Allows developers to organize their code however they see fit; the framework is not opinionated about code structure. - Allows developers to write code that is easily unit-testable. Avoids using thread local data structures which hamper testability. Provides helper APIs which make it easy to mock framework components such as templates and views. - Provides an optional declarative context-sensitive authorization system. This system prevents or allows the execution of code based on a comparison of credentials possessed by the requestor against ACL information stored by a BFG application. - Behavior of an an application built using BFG can be extended or overridden arbitrarily by a third-party developer without any
Re: [Web-SIG] Use 200 or 400 Status Code When...
Thomas, Unfortunately, it wasn't obvious to me that a 404 was appropriate in this situation. But, now that you mention it, I think you are right. Thank you for your input. -- Randy Syring RCS Computers Web Solutions 502-644-4776 http://www.rcs-comp.com Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 Thomas Broyer wrote: On Mon, Apr 27, 2009 at 4:32 AM, Randy Syring ra...@rcs-comp.com wrote: I have a page that accepts URL arguments like: /student/id The id must be an integer or the URL doesn't match and the user is given a 404. But what should I do if the id is given, is an integer, but a student with that id does not exist? I already output a message telling the user that they requested an invalid student. However, should that document have a 200 or 400 (or some other) status code? Obviously a 404 too, as the URL identifies something that doesn't exist. (in the case of an invalid id, i.e. not a number, you could use 410 status code too) ___ 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] empty action attribute with forms in Google Chrome
For the last four years, I have always used an empty action attribute on my form to make it post back to the current URL. I almost always validate my HTML and this has never come up as a violation. Furthermore, I have read various people on the web advocating this practice. Recently, however, I went to use Google Chrome to look at some of my web apps and I noticed that none of my forms work. In use a base tag and empty form attributes. Whenever I submit a form in Chrome, it gets posted to the root URL (i.e. what I have in my base tag). Am I violating the spec or is this something Google Chrome got wrong? What I have works in IE, FF, and Opera. Thanks. -- -- Randy Syring RCS Computers Web Solutions 502-644-4776 http://www.rcs-comp.com Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 ___ 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] Reverse Proxy HTTPS
Cameron Simpson wrote: On 04Apr2009 16:08, Randy Syring ra...@rcs-comp.com wrote: How tightly knit is the IIS i.e. do you have control over it? Maybe this rewrite thing should be set up in IIS instead, it seems the more obvious place for such control except that the rewrite config would no longer be part of the app. At least the IIS server should know if it's http or https. Or are you wanting to make your CherryPy app robust against http misuse? Disclaimer: I know close to nothing about IIS; this is just how I'd be approaching it with an Apache reverse proxy from end. Cheers, Cameron, Thanks for your reply. Let me start out by saying that I don't think this is an IIS issue, its just that IIS is the front-end web server that is proxying the HTTP requests through to the CherryPy server. If I was to choose to run a similar setup on a Linux box with Apache, I still think I would have the same question (feel free to correct me if I am wrong). I would like my application to have control over the HTTPS-HTTP redirects and would rather not force that logic into the forward facing web server if at all possible. That just seems like an extra configuration step that wouldn't necessarily be needed if I could figure out how to pass SSL status from the forward facing web server to the backend proxy (i.e. CherryPy and my app). So, do you (or anyone else) know of a good way to to this? Or, does everyone just assume that it is all or nothing for SSL when you are proxying to a backend? Thank you. -- Randy Syring RCS Computers Web Solutions 502-644-4776 http://www.rcs-comp.com Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 ___ 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] Reverse Proxy HTTPS
Graham,
Excellent, thank you! That confirms for me the concept is correct, now
all I have to do is work on an IIS implementation. FUN!
--
Randy Syring
RCS Computers Web Solutions
502-644-4776
http://www.rcs-comp.com
Whether, then, you eat or drink or
whatever you do, do all to the glory
of God. 1 Cor 10:31
Graham Dumpleton wrote:
Using nginx as front end to Apache/mod_wsgi as an example:
On nginx side you would use:
proxy_set_header X-Url-Scheme $scheme;
and on Apache/mod_wsgi side, with Django 1.0 as an example, in WSGI
script file we would have:
import os, sys
sys.path.append('/usr/local/django')
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
_application = django.core.handlers.wsgi.WSGIHandler()
def application(environ, start_response):
environ['wsgi.url_scheme'] = environ.get('HTTP_X_URL_SCHEME', 'http')
return _application(environ, start_response)
Is the equivalent on IIS side as others have mentioned that you need.
Graham
2009/4/7 Paweł Stradomski pstradom...@gmail.com:
W liście Randy Syring z dnia poniedziałek, 6 kwietnia 2009:
I would like my application to have control over the HTTPS-HTTP
redirects and would rather not force that logic into the forward facing
web server if at all possible. That just seems like an extra
configuration step that wouldn't necessarily be needed if I could figure
out how to pass SSL status from the forward facing web server to the
backend proxy (i.e. CherryPy and my app).
So, do you (or anyone else) know of a good way to to this? Or, does
everyone just assume that it is all or nothing for SSL when you are
proxying to a backend?
Check with IIS manual, it should be possible to set some nonstandard header
when the connection goes through SSL, and then check this header in your
application. Maybe that header is already there - write a simple controller
that prints all the headers from the request and check how it looks with and
without SSL (but verify with the IIS manual anyway).
--
Paweł Stradomski
___
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/graham.dumpleton%40gmail.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/randy%40rcs-comp.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] Reverse Proxy HTTPS
I have a Python application that I want to run with the CherryPy WSGI Server. My intention is to let the CherryPy server run on a non standard port (say 9001) and then let IIS (yes, I know what you are thinking, but that is what I have to work with) reverse proxy the website requests to CherryPy. However, I am wondering how I should handle HTTPS. Currently, there are only a few pages in my app that need HTTPS. When running the app natively in IIS, if one of those pages is requested using HTTP, I will issue a HTTP header redirect to the HTTPS page. How should I handle this in a reverse proxy situation? What I mean is, how do I detect in my Python app if the original request to IIS is using SSL? I don't want to have to run SSL on the connection from IIS to CherryPy. I am thinking I could modify the headers to the CherryPy server adding something like X-is-ssl and then use middleware on the python side to set wsgi.url_scheme appropriately. I just don't know the HTTP standard well enough to know how this kind of thing should be handled. Thank you for any help you can provide. -- -- Randy Syring RCS Computers Web Solutions 502-644-4776 http://www.rcs-comp.com Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 ___ 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] Implementing File Upload Size Limits
I did find this: http://wiki.pylonshq.com/display/pylonscookbook/A+Better+Way+To+Limit+File+Upload+Size Which was good, but still leaves some unanswered questions: * What if one is not using the paste http server? * This method gives an unfriendly response. What would be the best method to propagate this error condition down to the app so that a message could be given to the user in the context of the form they had previously submitted (i.e. an error message under the input field reminding them of the max upload size and even possibly telling them how big the file was they uploaded). Thanks. -- Randy Syring RCS Computers Web Solutions 502-644-4776 http://www.rcs-comp.com Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 Randy Syring wrote: I am looking for opinions and thoughts on best practice for limiting file upload size. I have a few considerations: * Ultimately, I would want my application with my method of handling forms to be able to give the user a message that the file size was too big. That means that however, the size is limited, just blanking out wsgi.input and setting content-length to zero doesn't seem correct. That would make it look like the form wasn't submitted with any data I believe. * Given the above, it seems that something would need to get put in the environment to tell middleware and the application that the file input was aborted, but what would be the best way for doing it? Should it be some kind of standard, or just dependent on your server or middleware? * It seems best to implement this functionality as the very first middleware in the stack. Since other middleware read and manipulate wsgi.input, handling the upload size at the application level wouldn't prevent middlware from wasting resources dealing with a very large file. Is it possible to prevent the server from even accepting all the data (i.e. trying to save bandwidth and server resources) if the content-length is known to be too big? Or is the server required to take all the client's data regardless, even if it ends up going in the bit bucket? I realize some of this is server specific, not WSGI specific, but I would be interested in knowing how the most popular servers handle this or what the HTTP specs require if anyone knows. Thanks in advance for any insight you might be able to provide. -- -- Randy Syring RCS Computers Web Solutions 502-644-4776 http://www.rcs-comp.com Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 ___ 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/randy%40rcs-comp.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] Implementing File Upload Size Limits
[forgot to copy list] Graham Dumpleton wrote: 2008/11/22 Randy Syring [EMAIL PROTECTED]: I am looking for opinions and thoughts on best practice for limiting file upload size. I have a few considerations: snip If you use Apache/mod_wsgi to host your WSGI application, the best way of handling this is use the Apache LimitRequestNody directive for appropriate context. This will result in Apache returning a HTTP_REQUEST_ENTITY_TOO_LARGE (413) error response to the client. If you need a custom error document for that response type use Apache ErrorDocument directive to specify URL of handler which would generate it. Graham, Thank you for your response. What you noted above does seem to be the lowest level solution possible if you are using apache. I suppose using an error document that is part of the application would at least allow me to serve a specific page from my application that could detail the error. If I wanted to get fancy, each time a form with an input element was sent to a user, I could save that path in a special variable in the user's session. My error page could then look for that value in the user session and if present, load the correct form, giving the user an error message noting that the file uploaded was too big. The downfall to that approach is that the form comes back empty. It might be better to just have the error page give them some details and encourage them to use the back button, in which case the form's fields would hopefully still be filled in. Except for the custom error document if delegated to the WSGI application, doing it this way results in it all being handled by Apache/mod_wsgi and your WSGI application will not even be invoked. The request body content would also not even be read by Apache at all. Do note that whether this avoids the client sending the request body input depends on whether the client was expecting a '100 Continue' response before it send the data. Most web browsers still I believe don't use '100 Continue' response. This would be the preferred solution for Apache/mod_wsgi as it is handled at lowest levels and guaranteed that request content wouldn't be read at that point. It is however taking control out of your application. Hopefully you can clarify something for me. Lets assume that the client does not use '100 Continue' but sends data immediately, after sending the headers. If the server never reads the request content, what does that mean exactly? Does the data get transferred over the wire but then discarded or does the client not get to send the data until the server reads the request body? I.e. the client tries to send it, but the content isn't actually transferred across the wire until the server reads it. I am just wondering if there is a buffer or queue or something between the server and the client that allows data to be transferred even if the server doesn't read the request body. Or, is it just like a straight pipe where one end (the client) can't push data through until the other end (the server) reads it. I agree that it does take control out of the application. From a usability perspective, the best solution IMO would be for the user to get the form back and have a red error messsage under the input field indicating the file size uploaded was too big and giving them the max file size allowed. However, on second thought, that may not be true. As noted above, because the entire request body was rejected, the form loaded would have none of the information they submitted and most users would probably think they have to fill out the whole form again. Probably better to just give them a non-form error page and let them use the back button (or even provide a link that uses javascript to go back) and in so doing hopefully salvage the time they put into the form. I suppose, though, that two different kinds of file size limits need to be thought through. The first limit would be an application wide limit that is set for security/resource reasons. That, I believe, is what we have been discussing up to this point. I am just realizing that it would also be fine to limit upload sizes at the application level and give more user-friendly error messages. So I might decide on a 10MB application-wide upload limit, but I might also restrict free accounts and paid accounts to 256k and 5MB respectively. As long as a user uploads something less than 10MB, they get a friendly in-line error message. If they upload over 10MB, we handle that at the apache level and send them to a custom error page. For Apache/mod_wsgi, if you do not do it this way but instead validate content length in the WSGI application and have the WSGI application return HTTP_REQUEST_ENTITY_TOO_LARGE (413) error response, then whether the request content gets read depends on whether you are using embedded mode or daemon mode of mod_wsgi. If you use embedded mode, so long as your WSGI application doesn't read the input and just returns the error
[Web-SIG] Implementing File Upload Size Limits
I am looking for opinions and thoughts on best practice for limiting file upload size. I have a few considerations: * Ultimately, I would want my application with my method of handling forms to be able to give the user a message that the file size was too big. That means that however, the size is limited, just blanking out wsgi.input and setting content-length to zero doesn't seem correct. That would make it look like the form wasn't submitted with any data I believe. * Given the above, it seems that something would need to get put in the environment to tell middleware and the application that the file input was aborted, but what would be the best way for doing it? Should it be some kind of standard, or just dependent on your server or middleware? * It seems best to implement this functionality as the very first middleware in the stack. Since other middleware read and manipulate wsgi.input, handling the upload size at the application level wouldn't prevent middlware from wasting resources dealing with a very large file. Is it possible to prevent the server from even accepting all the data (i.e. trying to save bandwidth and server resources) if the content-length is known to be too big? Or is the server required to take all the client's data regardless, even if it ends up going in the bit bucket? I realize some of this is server specific, not WSGI specific, but I would be interested in knowing how the most popular servers handle this or what the HTTP specs require if anyone knows. Thanks in advance for any insight you might be able to provide. -- -- Randy Syring RCS Computers Web Solutions 502-644-4776 http://www.rcs-comp.com Whether, then, you eat or drink or whatever you do, do all to the glory of God. 1 Cor 10:31 ___ 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
