-> > Sure. I'd suggest that we might want to expand it a little to include some
-> > of the fine contributions of other authors, such as Ian's "lint" middleware
-> > (which sits between an app and a server and checks both for compliance) and
-> > maybe even his "Python debugger in the browser" mid
At 11:12 PM 2/6/2006 -0800, Robert Brewer wrote:
>Ian Bicking said:
> > The HTTP server should always set SCRIPT_NAME to ''.
>
>Christian asked:
> > If it is a full blown WSGI compliant HTTP server,
> > why should it do that? Shouldn't it support mounting
> > applications at various points (SCRIPT_
I'm not sure what you're talking about here. Are you talking about
WSGI? Or the templating effort? I've tuned out the templating discussion.
I think you and others did a fantastic job with WSGI. (Based on my
experience I do think it needs more work in the future, but that's
beside the point.) D
At 09:08 AM 2/7/2006 -0500, Jim Fulton wrote:
>I'm not sure what you're talking about here. Are you talking about
>WSGI? Or the templating effort? I've tuned out the templating discussion.
Just the templating effort, and that only for the time being. I just don't
feel I have enough time to dev
Guido van Rossum wrote:
> On 2/5/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>>I suspect most templates will buffer their output internally, unless
>>somehow configured or dynamically set not to do so.
>
>
> Why would they? Isn't that a function that the web server typically does?
I've not see
Matt Goodall wrote:
> Guido van Rossum wrote:
>
>>On 2/5/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>
>>
>>>I suspect most templates will buffer their output internally, unless
>>>somehow configured or dynamically set not to do so.
>>
>>
>>Why would they? Isn't that a function that the web server
On Tuesday 07 February 2006 10:20, Phillip J. Eby wrote:
> >Despite some skepticism about the templating
> >effort, I certainly planned to evaluate it when it settled down.
>
> I'm not complaining about you personally tuning out; it's just that I ended
> up being a sole advocate for stuff I thought
Phillip J. Eby wrote:
>>Despite some skepticism about the templating
>>effort, I certainly planned to evaluate it when it settled down.
>
>
> I'm not complaining about you personally tuning out; it's just that I ended
> up being a sole advocate for stuff I thought Zope would need in order to
>
At 12:02 PM 2/7/2006 -0500, Stephan Richter wrote:
>BTW, did we reach a conclusion on the user logging issue. We really, really
>need to solve that somehow. Anything you can come up with is fine by me; I'll
>trust you do the right thing.
As I mentioned, you can do this right now by offering and do
At 11:12 AM 2/7/2006 -0600, Ian Bicking wrote:
>Maybe the reason those voices are missing -- I now realize -- is that
>there aren't many "active page" frameworks left.
All the more reason to encourage an approach that allows migrating existing
code written using those systems! :)
I think it's
On Tuesday 07 February 2006 12:28, Phillip J. Eby wrote:
> * Add an optional 'wsgi.response_filtering' key to the spec. If its value
> is present and true, the server promises to prevent 'X-Internal-*' headers
> from being transmitted.
>
> * Add an optional 'X-Internal-WSGI-Authenticated-User' hea
On Tue, 07 Feb 2006 11:12:04 -0600, "Ian Bicking" <[EMAIL PROTECTED]>
said:
> Maybe the reason those voices are missing -- I now realize -- is that
> there aren't many "active page" frameworks left. Spyce was, but since
> then I believe a more traditional controller-driven API has been added
Ye
On Tue, Feb 07, 2006 at 11:12:04AM -0600, Ian Bicking wrote:
> Maybe the reason those voices are missing -- I now realize -- is that
> there aren't many "active page" frameworks left.
Yup. SkunkWeb too, which like Myghty also started out as a port of
Mason, now has a controller framework, with
Phillip J. Eby wrote:
> So, if there are no objections, I propose that we:
>
> * Add an optional 'wsgi.response_filtering' key to the spec. If its value
> is present and true, the server promises to prevent 'X-Internal-*' headers
> from being transmitted.
>
> * Add an optional 'X-Internal-WSGI
At 11:50 AM 2/7/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>So, if there are no objections, I propose that we:
>>* Add an optional 'wsgi.response_filtering' key to the spec. If its
>>value is present and true, the server promises to prevent 'X-Internal-*'
>>headers from being transmi
Phillip J. Eby wrote:
> The only time you should set SCRIPT_NAME to "" is if the
> application object being executed is mounted at the server
> root. So, this is correct behavior for a server like
> wsgiref's SimpleHTTPServer, which does not provide any
> mount points. If your server implements
At 12:18 PM 2/7/2006 -0800, Robert Brewer wrote:
>Here's my continuing issue: if we allow middleware to implement mount
>points, then your first statement (above) needs to be modified to:
>
> The only time [the origin server] should set SCRIPT_NAME
> to "" is if the application object being
Robert Brewer wrote:
> Phillip J. Eby wrote:
>
>>The only time you should set SCRIPT_NAME to "" is if the
>>application object being executed is mounted at the server
>>root. So, this is correct behavior for a server like
>>wsgiref's SimpleHTTPServer, which does not provide any
>>mount points.
On Feb 7, 2006, at 12:28 PM, Phillip J. Eby wrote:
> * Add an optional 'wsgi.response_filtering' key to the spec. If
> its value
> is present and true, the server promises to prevent 'X-Internal-*'
> headers
> from being transmitted.
>
> * Add an optional 'X-Internal-WSGI-Authenticated-User' h
Phillip J. Eby wrote:
> > 1. If "the application" refers to the end app or framework
> > 2. "The application" could refer to the routing-middleware
>
> "Application" simply refers to any code that is reading an
> 'environ' that it received from *its* server. So *both*
> of these are "applicatio
I'd very much like to see a _usable_ WSGI server included in the
standard Python library: I don't care how it is done.
It should have a few requirements:
- it should obviously implement all of WSGI that is required by a
server implementation;
- it should be stand-alone, only dependent up
Clark C. Evans wrote:
> I'd very much like to see a _usable_ WSGI server included in the
> standard Python library: I don't care how it is done.
>
> It should have a few requirements:
> ...
> - it should _not_ have any functionality beyond the
> minimums required by WSGI: specificially, it
Phillip,
You are correct, I'm convinced that response headers are the place
to include this sort of inter-middleware communication.
On Tue, Feb 07, 2006 at 12:28:09PM -0500, Phillip J. Eby wrote:
| * Add an optional 'wsgi.response_filtering' key to the spec. If its value
| is present and true,
On Tue, Feb 07, 2006 at 04:38:02PM -0800, Robert Brewer wrote:
| > - it should _not_ have any functionality beyond the
| > minimums required by WSGI: specificially, it should
| > not handle multiple WSGI applications (routing)
|
| Having just added routing to CherryPy's WSGI server in l
At 08:22 PM 2/7/2006 -0500, Clark C. Evans wrote:
>I absolutely love wsgi.response_filtering, only I feel that it should be
>a *mutable* listing of the headers that the server should strip. If
>the list is not present, then response filtering is not available. In
>particular, I think that requring
25 matches
Mail list logo
