s on Python 3 or WSGI 3.0
applications on Python 2.x.
Regards,
Brian
___
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
and
> saying "just inject this into file X at line Y" -- not pretty.
> However, I have to admit, that if taken as an iterative improvement
> over file/function name it looks very reasonable.
Seems like this style of declaring routes may be more like what you
want:
http://bo
Alan Kennedy wrote:
> [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!
HTTPbis *is* (will be) HTTP/1
Robert Brewer wrote:
> Brian Smith wrote:
> > Here is the change that removes the use of RFC 2047 from HTTP in
> > HTTPbis.
>
> Yes, but parsers need to continue decoding them for many years to come.
> IMO WSGI origin servers should do this so we can write the decoding
Here is the change that removes the use of RFC 2047 from HTTP in HTTPbis.
-Original Message-
From: ietf-http-wg-requ...@w3.org [mailto:ietf-http-wg-requ...@w3.org] On
Behalf Of Mark Nottingham
Sent: Monday, April 06, 2009 5:00
To: HTTP Working Group
Subject: Closing #63: RFC2047 encoded wo
Brian Smith wrote:
> 2008/11/26 Brian Smith <[EMAIL PROTECTED]>:
> > Under Apache CGI or mod_wsgi, in many situations you will get a
> > deadlock in this scenario.
>
> It isn't 'many situations', it is a quite specific situation.
Right. I meant that i
e file size on
the client and prevent these requests from even being made (in the typical
case). You will still have to implement the validation logic on the server
to prevent malicious use and/or disabled Javascript/Flash/Java. There are
additional benefits to this approach (better UI, multi-fi
>Manlio Perillo wrote:
>> Brian Smith wrote:
>> For "non-blocking reads", given environ["wsgi.input"].read(64000,
>> min=8000):
>>
>> 1. If more than 64000 bytes are available without blocking, [64000] bytes
>> are returned.
>> 2.
Manlio Perillo wrote:
> Brian Smith ha scritto:
> > We already have standard mechanisms for doing something
> > similar in WSGI: multi-threaded and multi-process WSGI
> > gateways that let applications block indefinitely while
> > letting other applications run.
>
mit that I am not totally across what the HTTP 102
> status code is meant to be used for and am sort of presuming
> that this might make sense. Am sure though that Brian who
> understands this sort of level better than me will set me straight.
The application should definitely be able
Manlio Perillo wrote:
> Brian Smith ha scritto:
> > Manlio Perillo wrote:
> >> Fine with me but there is a *big* problem.
> >>
> >> WSGI 2.0 "breaks" support for asynchronous applications (since you
> >> can no more send headers in the
y 2xx or 3xx
code, which is basically what James Knight suggested (sorry James). The
gateway must indicate EOF if only a partial request body was received. I
don't think the gateway should be required to provide any of the partial
request content on a 4xx, though.
- Brian
___
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
x27;s close() method, MUST NOT read from
wsgi.input.
Thoughts?
- Brian
___
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
away. In other words a zero
> length read must always be passed through unless specifically
> not appropriate for what the WSGI middleware is doing.
>
> This would be required to ensure that zero length read always
> propagates down to the web server layer itself such
"100 Continue" itself, like this:
def application(environ, start_response):
start_response("100 Continue", [])
yield ""
start_response("200 OK", [])
yield "OK"
The reasons is that sta
e request body at its own
discretion. The last time I checked, Lighttpd and nginx both cached the
entire request body before handing it off to back end [Fast|S]CGI
processes. Most web accelerator proxies work the same way.
I do agree that it should not be *required* be
le of this use case?
PEP 333 allows the WSGI gateway to buffer the input if it chooses to do
so: "The server or gateway may perform reads on-demand as requested by
the application, or it may pre- read the client's request body and
buffer it in-memory or on disk, or u
Graham Dumpleton wrote:
> On 26/01/2008, Brian Smith <[EMAIL PROTECTED]> wrote:
> As to your questions about read() with no argument, or with
> traditional Python file like object default of -1, the only
> WSGI server/adapter I know of where this will NOT work as one
> wo
James Y Knight wrote:
> On Jan 25, 2008, at 10:04 AM, Brian Smith wrote:
> > 1. PEP 333 doesn't indicate that the size parameter for the read()
> > method is optional. Is it optional or required? If it is
> > optional, is the default value -1?
>
> The spec says
on["wsgi.input"].read(-1)
This is another issue where there is a lot of variance between gateways, where
I think a clarification in the specification is needed.
- Brian
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.or
Worked out better
> than I expected then. :-)
I will double-check, but I believe that in the embedded mode, the file
never gets read at all, when there are no output filters processing the
output. I will bring it up on the mod_wsgi list.
> Except as pointed out that 2 suggests I should ne
> theory, I suspect it would require a very complex protocol
> (more complex than what WSGI requires now).
That is exactly what WSGI is designed for. There is no point to having a
standard if there is no interoperability amongst compliant components.
- Brian
_
>through the response iterable, but it must call the
>response iterable's close() method, if any. It must not
>send any output that was written via
>start_response(...).write() either. Consequently,
>WSGI applications must work correctly, and must not
>
gnal
or log an error if the iterable's close() method is invoked without any
iteration taking place.
Please add this issue to http://wsgi.org/wsgi/WSGI_2.0.
Regards,
Brian
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sig
Ian Bicking wrote:
> We encountered it with GData too, as it uses URLs like
> /{http:%2f%2fexample.com}term/. But if you balance the {}'s
> you can parse it out.
Unquoted curly braces are illegal in any kind of URI or IRI. Does GData
really require them to be unqu
be set and manipulated by dispatching middleware only. If NGinx's
mod_wsgi sets the wsgiorg.routing_args, but dispatching middlewhere
layered on top of it does not update it, then the application will end
up being misinformed.
- Brian
___
Web-SIG mail
Luis Bruno wrote:
> Brian Smith wrote:
> > An ammendment that recommends, but does not require,
> > REQUEST_URI is a much better option.
>
> Thereby forcing me to shop around for a WSGI server that
> actually puts the recommendation into practice? Because I
>
> [/Laptops/LN500%2F9DW/ ] would be the Right Thing, except for not
> > being WSGI.
> Looks to me like a good candidate for an amendment.
>
> What's the next step?
Something so fundemantal as this cannot be changed with a simple
ammendment to the existing specification. Suc
ent-Length header, or at least avoid the need to close the client
connection."
I do think think that it is a good idea to include these clarifications
in (an addendum to) the WSGI spec, as these are all issues that are
often overlooked in implementations.
- Brian
___
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
different files.
I agree, but (a) that would have to be standardized somewhere to be
useful, and (b) you still have to deal with code that isn't aware of
this new functionality--especially libraries that are not WSGI-specific,
and existing WSGI 1.0 applications.
- Brian
___
you
> more want to be able to filter and route logs by component
> *instance* (e.g. which page of your web app is being rendered)
> than by code module (e.g. templating library vs. db library).
The built-in logging module allows you to do this
Manlio Perillo wrote:
> Graham Dumpleton ha scritto:
> > On 21/12/2007, Brian Smith <[EMAIL PROTECTED]> wrote:
> >> The specification should then also explicitly say
> >> that WSGI applications should not redirect logging
> >> output to wsgi.errors or anyw
output location. Every WSGI gateway has to do this anyway to handle
non-WSGI-aware modules that use the python logging module. The
specification should then also explicitly say that WSGI applications
should not redirect logging output to wsgi.errors or anywhere else. In
fact, if that
urned 200 OK then you have to assume that they returned a full
response. At that point, you can examine the cache validators and Vary
headers in the response to determine whether or not it is safe to
convert the response into a 206. That is all explained in RFC 2616.
There is not much room f
t;file" at the time that transmission begins, and continue
until the end is reached."
It doesn't support sending a file *up to* a specific offset, though,
which I think is unfortunate.
- Brian
___
Web-SIG mailing list
Web-SIG@python.org
Web
On Mon, Mar 12, 2007 at 10:01:20AM -0400, Jim Fulton wrote:
>
> On Mar 12, 2007, at 1:26 AM, Brian Sutherland wrote:
>
> > On Fri, Mar 09, 2007 at 01:22:58PM -0500, Chad Whitacre wrote:
> >> Jim,
> >>
> >> First, your comments re: paying attentio
g
compatibility/extending a distutils style installation.
--
Brian Sutherland
___
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
be flexible enough
> to meet your requirements?
>
>
>
>
> chad
> ___
> 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/jinty%40web.de
but I came across XIST and it seems to include a pretty
'complete' way of doing that:
http://www.livinglogic.de/Python/xist/Examples.html
--
Brian Beck
Adventurer of the First Order
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://
Brian Beck wrote:
little about each but still can't put my finger on it. Is she geared
toward a specific type of application?
Whoops. That should read 'Is *each* geared toward a specific type of
application?'
--
Brian Beck
Adventurer of
ry) of the
advantages/disadvantages (in comparison to each other) of frameworks
like PEAK, WebWare, nevow, and anything else applicable? I've read a
little about each but still can't put my finger on it. Is she geared
toward a specific type of application?
Any help would be apprec
41 matches
Mail list logo
