Re: [Web-SIG] New spec: throw_errors

> I _want_ composability and decomposability. > That is the exact approach I would like to see. > Let's encourage this kind of understanding. +1 To me, this is the biggest selling point for using WSGI at all. Ted -- Edward O'Connor [EMAIL PROTECTED] Ense petit placidam sub libertate quietem.

Re: [Web-SIG] New spec: throw_errors

On 11/14/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > Luke Arno wrote: > > On 11/14/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > >> Luke Arno wrote: > >> > -1 to the proposed spec > >> > > >> > On 11/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > >> > ... > >> >> Other Possibilities > >> >> --

Re: [Web-SIG] New spec: throw_errors

Luke Arno wrote: > On 11/14/06, Ian Bicking <[EMAIL PROTECTED]> wrote: >> Luke Arno wrote: >> > -1 to the proposed spec >> > >> > On 11/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote: >> > ... >> >> Other Possibilities >> >> --- >> >> >> >> * You can just get the unwrapped application

Re: [Web-SIG] New spec: throw_errors

Robert Brewer wrote: > Ian Bicking wrote: >>http://wsgi.org/wsgi/Specifications/throw_errors >> ... >> Problems >> >> >> * In theory an application may know better how to format an error >> response than the middleware exception catcher. Of course, an >> application can ignore ``x-w

Re: [Web-SIG] New spec: throw_errors

On 11/14/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > Luke Arno wrote: > > -1 to the proposed spec > > > > On 11/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > > ... > >> Other Possibilities > >> --- > >> > >> * You can just get the unwrapped application object and test it. > > > >

Re: [Web-SIG] New spec: throw_errors

Ian Bicking wrote: >http://wsgi.org/wsgi/Specifications/throw_errors > ... > Problems > > > * In theory an application may know better how to format an error > response than the middleware exception catcher. Of course, an > application can ignore ``x-wsgiorg.throw_errors`` if it th

Re: [Web-SIG] New spec: simple authentication

Sylvain Hellegouarch wrote: > Ian, > > > Why disallowing the application to set the WWW-Authenticate header? If a > middleware is present it will be overwritten anyway. If no middleware is > there then at least you won't break the first MUST in section 10.4.2 of > RFC 2616. I suppose there's no

Re: [Web-SIG] New spec: throw_errors

Luke Arno wrote: > -1 to the proposed spec > > On 11/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > ... >> Other Possibilities >> --- >> >> * You can just get the unwrapped application object and test it. > > +1, emphatically > > Let's encourage best practices, before we > stand

Re: [Web-SIG] New spec: throw_errors

-1 to the proposed spec On 11/13/06, Ian Bicking <[EMAIL PROTECTED]> wrote: ... > Other Possibilities > --- > > * You can just get the unwrapped application object and test it. +1, emphatically Let's encourage best practices, before we standardize specific workarounds. The unwra

Re: [Web-SIG] (proto) request object spec

On 11/14/06, William Dode <[EMAIL PROTECTED]> wrote: > On 14-11-2006, Phillip J. Eby wrote: > > At 06:36 PM 11/13/2006 -0700, L. C. Rees wrote: > > ... > > >>Operations that produce entries such as these are frequently performed > >>by > >>middleware. > > > > This is not what middleware is for; ple

Re: [Web-SIG] (proto) request object spec

On 14-11-2006, Phillip J. Eby wrote: > At 06:36 PM 11/13/2006 -0700, L. C. Rees wrote: ... >>Operations that produce entries such as these are frequently performed >>by >>middleware. > > This is not what middleware is for; please don't encourage people to do > this. Library functions are the O

Re: [Web-SIG] New spec: simple authentication

Ian, Why disallowing the application to set the WWW-Authenticate header? If a middleware is present it will be overwritten anyway. If no middleware is there then at least you won't break the first MUST in section 10.4.2 of RFC 2616. What happens if part of my application is to be protected by Op