I don't see this relevant message in your references.
https://mail.python.org/pipermail/web-sig/2004-September/000749.html
Perhaps that, and following messages, might shed more light?
On Thu, Mar 24, 2016 at 3:18 PM, Jason Madden
wrote:
> Hi all,
>
>
> Is there any practical reason that the ty
[Cory Benfield]
> Folks, just a reminder: RFC 2616 is dead. RFC 7230 says that *newly
defined* header
> fields should limit their field values to US-ASCII, but older header
fields are a
> crapshoot (though it notes that “in practice, most” header field values
use US-ASCII).
>
> Regardless, it seems
014 at 10:14 PM, Collin Anderson
wrote:
> Thanks guys. So it sounds like it should be the responsibility of a
> middleware to re normalize the environment?
>
> On Wed, Sep 24, 2014 at 4:51 PM, Robert Collins > wrote:
>
>> On 25 September 2014 07:16, Alan Kennedy wrote:
>
[Collin]
> It seems to me, it is the role of the server/gateway, not the
> application/framework to determine the "correct" client ip address and
> correctly account for the situation of being behind a known proxy.
I disagreee. I think it is the role of the server/gateway to represent the
actual i
[anatoly]
> Martin expressed concerns that using logging module with stderr output
> can break web applications, such as PyPI.
Please can you specify exactly what you mean by "using logging module
with stderr output"?
Dealing with stderr is a webserver specific concern.
Consider the case where y
[PJ Eby]
> IOW, the bytes/string discussion on Python-dev has kind of led me to realize
> that we might just as well make the *entire* stack bytes (incoming and
> outgoing headers *and* streams), and rewrite that bit in PEP 333 about using
> str on "Python 3000" to say we go with bytes on Python 3+
[Armin]
> Of course a server configuration variable would be a solution for many
> of these problems, but I don't like the idea of changing application
> behavior based on server configuration.
So you don't like the way that Django, Werkzeug, WebOb, etc, do it
now, even though they appear to be mo
[Armin]
> No, they know the character sets.
Hmmm, define "know" ;-)
[Armin]
> You tell them what character set you
> want to use. For example you can specify "utf-8", and they will
> decode/encode from/to utf-8. But there is no way for the application to
> send information to the server before
[Armin]
> Because that problem was solved a long ago in applications themselves.
> Webob, Werkzeug, Paste, Pylons, Django, you name it, all are operating
> on unicode. And the way they do that is straightforward.
So what are we all discussing?
Those frameworks obviously have solved all of the pr
[Alan]
>> Is there a real need out there?
[Armin]
> In python 3, yes. Because the stdlib no longer works with bytes and the
> bytes object has few string semantics left.
Why can't we just do the same as the java servlet spec? I.E.
1. Ignore the encoding issues being discussed
2. Give the progra
[P.J. Eby]
>> Actually, latin-1 bytes encoding is the *simplest* thing that could
>> possibly work, since it works already in e.g. Jython, and is actually
>> in the spec already... and any framework that wants unicode URIs
>> already has to decode them, so the code is already written.
[Armin]
> E
[Ian]
> When things get messed up I recommend people use a middleware
> (paste.deploy.config.PrefixMiddleware, though I don't really care what they
> use) to fix up the request to be correct. Pulling it from REQUEST_URI would
> be fine.
That would be unworkable under java servlet containers, sinc
[Ian]
>> OK, another proposal entirely: we kill SCRIPT_NAME and PATH_INFO
>> introduce two equivalent variables that hold the NOT url-decoded values.
[Graham]
> That may be fine for pure Python web servers where you control the
> split of REQUEST_URI into SCRIPT_NAME and PATH_INFO in the first pla
[Rene]
>> I think you mean pre-2.2 support, not python 2.2? iterators came
>> about in python 2.2.
[Armin]
> That might be. That was before my time. I'm pretty sure the first
> Python version I used was 2.3, but don't quote me on that.
As WSGI was being developed, cpython was at version 2.3.
[Etienne]
> If you want to start a thread for Bobo, please switch mailing-list or
> create a new thread, as all I wanted was to tell Jim my disappointement
> regarding Bobo, and I still think its not very revolutionary.
I completely disagree; this is definitely the appopriate list for
discussing w
[Pete]
> Any interest in a dedicated email list for REST + python, a la the
> restful-json group [0]? The group would discuss strategies for REST
> architecture built with and within Python. WSGI 1.0 vs. 2.0 vs. 2e6 is out
> of scope. ;-)
Just a thought: is there any reason why RESTful python di
[Brian]
> Here is the change that removes the use of RFC 2047 from HTTP in HTTPbis.
Grand so; all we need to do is to wait for everyone to stop using
HTTP/1.1, start using HTTP/bis, and our problems are at an end!
;-)
Alan.
___
Web-SIG mailing list
Web
[James]
> If you want to start a discussion about having a standard parsed-header
> object in WSGI, that's another thing, but saying that WSGI servers should
> *partially* decode the headers seems rather silly to me.
Hi James,
It's a shame that your proposal to add the twisted header parsing
libr
[Sylvain]
> Would there be any interest in asking the HTTP-BIS working group [1] what
> they think about it?
>
> Currently I couldn't find anything in their drafts suggesting they had
> decided to clarify this issue from a protocol's perspective but they might
> consider it to be relevant to their
[Sylvain]
> Would there be any interest in asking the HTTP-BIS working group [1] what
> they think about it?
>
> Currently I couldn't find anything in their drafts suggesting they had
> decided to clarify this issue from a protocol's perspective but they might
> consider it to be relevant to their
[Noah]
> +1 on the iterator, although I might just like the idea and might be missing
> something important. It seems like there are a lot of powerful things being
> developed with generators in mind, and there are some nifty things you can
> do with them like the contextlib example:
> http://doc
Hi Bill,
[Bill]
> I think the controlling reference here is RFC 3875.
I think the controlling references are RFC 2616, RFC 2396 and RFC 3987.
RFC 2616, the HTTP 1.1 spec, punts on the question of character
encoding for the request URI.
RFC 2396, the URI spec, says
"""
It is expected that a
Hi Graham,
I think yours is a good solution to the problem.
[Graham]
> In other words, leave all the existing CGI variables to come through
> as latin-1 decode
As latin-1 or rfc-2047 decoded, to unicode.
> and do anything new in 'wsgi' variable namespace,
So the server provides
"wsgi.server_d
Hi all,
It was great to meet (nearly) everybody at PyCon; I look forward to
the next time.
I particularly want to thank Robert for being so meticulous about
recording and reporting the discussions; a necessary part of moving
forward, IMO.
[Robert]
> H. Graham brought up chunked requests whic
Dear all,
For those of you at PyCon, there is a WSGI Open Space @ 5pm today (Friday).
The sub-title of the open space is "Does WSGI need revision"?
An example: Philip Jenvey (http://dunderboss.blogspot.com/) raised the
need for something akin to what Java folks call "Lifecycle methods",
so that
[David]
> Can we use both Python and Javascript in html webpages? Any demo on this?
If you're willing to write rpython, PyPy can compile it to javascript
which run can in a browser.
http://codespeak.net/pypy/dist/pypy/doc/js/using.html
HTH,
Alan.
__
[Graham]
> I would be for (1) errata or amendment as reality is that there is
> probably no WSGI implementation that disallows an argument to
> readline() given that certain Python code such as cgi.FieldStorage
> wouldn't work otherwise.
>
> For such a clarification on existing practice, I see no p
[Graham]
> Thus, is an embedded newline in value invalid? Would it be reasonable
> for a WSGI adapter to flag it as an error?
>From a security POV, it may be advisable for WSGI servers to *not*
allow newlines in HTTP response headers; newlines in response headers
may be the result of an applicatio
[Bob]
> simplejson would give you an error and tell you exactly where the
> problem was,
Another good point.
Other JSON modules should follow simplejson's lead, and provide access
to the location in the document where the lexical or parse error
occurred, so that the offending document can be op
[Alan]
>> [hand written JSON containing a] hard-to-spot dangling comma, from all the
>> copying and pasting. That broke his javascript library; he solved the
>> problem by passing it through a PHP JSON codec on his local Apache. It
>> worked, i.e. his problem disappeared, but he didn't know why
[John]
> I'm interested in whether you generally use JSON to communicate with a
> JavaScript client, or another JSON library. Both the demjson and simplejson
> libraries are written with the assumption that they are to be used to
> interact with JavaScript.
Answer #1: My motive is simply to implem
[Alan]
>> [2] Perhaps some pythonista from Web-SIG is most appropriate to advise
>> how JSON-RPC should move forward? After all, we're more accustomed to
>> server-side stuff than those javascript folks ;-)
[Ian]
> Let it die? It is more complicated than necessary, when instead you could
> just
[Ronny]
>> since json-rpc and xml-rpc basically do the same
>> and the only difference is the content-type (json is more concise),
>> i propose to create a single xml/json-rpc module.
[Graham]
> The problem with the JSON-RPC 1.0 specification was that it wasn't
> always as clear as could have
[Deron]
> (I just joined this list, so this reponse may not be threaded properly)
[Bob]
> I wasn't subscribed to the list at the time this came up, but I'm all
> for getting simplejson into the stdlib.
Well, it appears we have a quorum of JSON<->python codec writers,
since I've written a jython m
[Massimo]
> It would also be nice to have a common interface to all modules that
> do serialization. For example pickle, cPickle, marshall has dumps, so
> json should also have dumps.
Indeed, this is my primary concern also.
The reason is that I have a pure-java JSON codec for jython, that I
will
[Graham]
> The problem areas were, different interpretations of what could be
> supplied in an error response. Whether an integer, string or arbitrary
> object could be supplied as the id attribute in a request. Finally,
> some JavaScript clients would only work with a server side
> implementa
Dear all,
Given that
1. Python comes with "batteries included"
2. There is a standard library re-org happening because of Py3K
3. JSON is now a very commonly used format on the web
Is it time there was a JSON codec included in the python standard library?
(If XML is already supported, I see n
[Alan]
>> The restriction to iso-8859-1 is really a distraction; iso-8859-1 is
>> used simply as an identity encoding that also enforces that all
>> "bytes" in the string have a value from 0x00 to 0xff, so that they are
>> suitable for byte-oriented IO. So, in output terms at least, WSGI *is*
>> a
[Phillip]
>> WSGI already copes, actually. Note that Jython and IronPython have
>> this issue today, and see:
>>
>> http://www.python.org/dev/peps/pep-0333/#unicode-issues
[James]
> It would seem very odd, however, for WSGI/python3 to use strings-
> restricted-to-0xFF for network I/O while everyw
Dear all,
Now that jython 2.2 has been released (hooray!)
http://www.jython.org/Project/download.html
it's time for a quick update on the status of modjy, the jython
WSGI/J2EE gateway.
http://www.xhaus.com/modjy/
Previous versions of modjy were based on jython 2.1, which didn't have
support
[Graham Dumpleton]
> First comment is about WSGI applications somehow themselves using
> SIGTERM etc as triggers for things they want to do. For Apache at
> least, allowing any part of a hosted Python application to register
> its own signal handlers is a big no no. This is because Apache itsel
[Alan Kennedy]
>>Strictly speaking, WSGI requires python 2.2,
>>because of iterators.
[Phillip J. Eby]
> Actually, it doesn't. The pre-2.2 iterator protocol is to be used in such
> cases:
>
> http://www.python.org/dev/peps/pep-0333/#supporting-older-2-2-versi
Graham,
I thought I'd reply, so that we'd get replies from everyone else to
tell me I'm wrong.
All your points are good common-sense stuff. I think that all of your
policies on stdin, stdout, and stderr are good, and are appropriate
for a WSGI environment running inside an Apache server.
Some sm
[Graham Dumpleton]
> Should a WSGI adapter for a web server which allows a mount point to
> have a trailing slash specifically flag as a configuration error an
> attempt to use such a mount point given that it appears to be
> incompatible with WSGI?
OK, I'll have a go.
I think the question boils
[Graham]
> Hmmm, maybe I should have phrased my question a bit differently as to be
> honest I am not actually interested in doing on the fly decompression and
> only used it as an example. I really only want to know about how the
> content length is supposed to be dealt with. I didn't want to expl
[Graham Dumpleton]
> How does one implement in WSGI an input filter that manipulates the request
> body in such a way that the effective content length would be changed?
> The problem I am trying to address here is how one might implement using WSGI
> a
> decompression filter for the body of a re
[Peter Hunt]
>> I think an interesting project would be complete integration of the
>> client and server via AJAX. That is, whenever a DHTML event handler
>> needs to be called on the client-side, the document state is serialized
>> and it is sent along with the DHTML event information to the serve
[Titus Brown]
> I'm thinking of proposing a project to build a JavaScript interpreter
> interface for Python; the goal (for me) is to get twill/mechanize to
> understand JavaScript. I think the project has wider applications,
> but I'm not sure what people actually want to do with JavaScript.
> I
[Alan Kennedy]
> But I'm tired of hacking on it to make it do what I want: I'd much
> prefer to start afresh with my own design than to continue to use
> Quixote: it's just too limiting.
[Titus Brown]
> I think you mistook my question for a criticism ;). Rewrite or no,
[Alan Kennedy]
> I'm looking for a framework-independent form library. I'm using the
> Quixote forms library at the moment, inside my own framework, but
> would ideally like something more WSGI oriented, so that it is easier
> to mock and unittest.
[Titus Brown]
> I&#
[Alan Kennedy]
> I'm looking for a framework-independent form library. I'm using the
> Quixote forms library at the moment, inside my own framework, but
> would ideally like something more WSGI oriented, so that it is easier
> to mock and unittest.
[Daniel Miller]
&g
Greetings All.
I'm looking for a framework-independent form library. I'm using the
Quixote forms library at the moment, inside my own framework, but
would ideally like something more WSGI oriented, so that it is easier
to mock and unittest.
My ideal form framework should do the following
1. Pars
[Alan Kennedy]
>>>Maybe we need a PEP
[Bill Janssen]
>>Great idea! That's exactly what I thought when I organized this SIG a
>>couple of years ago.
[Guido van Rossum]
> At first I was going to respond "+1". But the fact that a couple of
> ye
this several times (well, not wsgiref's implementation, but
> paste.response.HeaderDict). rfc822 is heavier than this dictionary-like
> object, and apparently is also deprecated.
[Alan Kennedy]
> While we're on the subject, can we find a better home for the HTTP
> status codes->message
[Ian Bicking]
> Anyway, I'm +1 on the object [wsgiref's wsgi header manipulation class]
> going somewhere. I don't know if the
> parent package has to be named "wsgi" -- and "wsgiref" seems even
> stranger to me, as anything in the standard library isn't a "reference
> implementation" anymore, but
[Robert Brewer]
> Look at the right code and see if your gut feeling changes. ;)
I looked at
http://svn.cherrypy.org/trunk/cherrypy/_cphttpserver.py
As indicated by Ian in this message
http://mail.python.org/pipermail/web-sig/2006-February/002074.html
Sorry if that was the wrong one to look at
[Alan Kennedy]
>>Priority #1: Make the requisite server a single standalone module.
[Guido van Rossum]
> Huh? What makes you think this?
My bad :-(
Two things made me think like that
1. BaseHttpServer -> BaseHttpServer.py
SimpleHttpServer -> SimpleHttpServer.py
[Guido van Rossum]
Let's make it so. I propose to add wsgiref to the standard library and
nothing more.
[Blake Winton]
>>>Will you be maintaining this? ;)
[Guido van Rossum]
>>I'd expect we could twist Phillip's arm to maintain it; he's not
>>expecting much maintenance.
[Phillip J. Eby]
[Alan Kennedy]
3. If I had to pick one of the 3 you suggested, I'd pick the
last one, i.e. PJE's, because it fulfills exactly the criteria
I listed
[Robert Brewer]
I have to disagree (having examined/unraveled it quite a bit recently,
to remove modpython_gateway's dependency
[Ian Bicking]
> Note that the scope of a WSGI server is very very limited. It is quite
> distinct from an XMLRPC server from that perspective -- an XMLRPC server
> actually *does* something. A WSGI server does nothing but delegate.
and
> I'm not set on "production" quality code, but I think t
[Alan Kennedy]
>> Looking at this in an MVC context ...
[Phillip J. Eby]
> As soon as you start talking about what templates should or should not
> do (as opposed to what they *already* do), you've stopped writing an
> inclusive spec and have wandered off into evang
[Graham Dumpleton]
> Anyway, not that it matters, but the security fix was not the only thing
> in those releases.
Still, I think my point stands that internet-facing servers in the
standard lilbrary are currently the only source of security advisories
in python.
http://www.python.org/security/
[Alan Kennedy]
>>Instead, I think the right approach is to continue with the existing
>>approach: put the most basic possible WSGI server in the standard
>>library, for educational purposes only, and a warning that it shouldn't
>>really be used for production
If you had given up on
> convincing me then, or if I had given up on your use cases as "too
> complex", the spec would have suffered for it.
And I am indeed most grateful that you took the time to understand my
tiresome ramblings on the subject: WSGI is indeed a most excellent spe
[Guido van Rossum]
> I see. But doesn't this still tie the templates API rather strongly to
> a web API? What if I want to use a template engine to generate
> spam^H^H^H^Hpersonalized emails? Or static HTML pages that are written
> to the filesystem and then served by a classic Apache setup? Or
[Peter Hunt]
> I think CherryPy's WSGI server should go in: it's stable, and the
> best-performing WSGI HTTP server out there.
I disagree.
I think that if a WSGI server is to go into the standard library, it
should be the most basic one possible, e.g. one that builds on the
*HttpServer.py hier
[Clark C. Evans]
> I'd stick with the notion of a "template_name" that is neither the
> template file nor the template body. Then you'd want a template factory
> method that takes the name and produces the template body (complied if
> necessary).
I agree.
If you're looking for an existing mode
[Alan Kennedy]
>> I agree about not sending this information back to the user: it's
>> unnecessary and potentially dangerous.
[Phillip J. Eby]
> Yep, it would be really dangerous to let me know who I just logged in to
> an application as. I might find out who I re
;t be logging auth information.
I agree about not sending this information back to the user: it's
unnecessary and potentially dangerous.
Regards,
Alan Kennedy.
___
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
69 matches
Mail list logo
