[Web-SIG] Prototype of wsgi.input.readline().

2008-01-30 Thread Graham Dumpleton
As I think we all know, no one implements readline() for wsgi.input as defined in the WSGI specification. The reason for this is that stuff like cgi.FieldStorage would refuse to work and would just generate an exception. This is because cgi.FieldStorage expects to pass an argument to readline().

Re: [Web-SIG] Prototype of wsgi.input.readline().

2008-01-30 Thread Chris McDonough
Graham Dumpleton wrote: As I think we all know, no one implements readline() for wsgi.input as defined in the WSGI specification. The reason for this is that stuff like cgi.FieldStorage would refuse to work and would just generate an exception. This is because cgi.FieldStorage expects to pass

Re: [Web-SIG] HTTP 1.1 Expect/Continue handling

2008-01-30 Thread Brian Smith
Graham Dumpleton wrote: On 29/01/2008, James Y Knight [EMAIL PROTECTED] wrote: a) One is to clarify this as a requirement upon the WSGI gateway. Something like the following: If the client requests Expect: 100-continue, and the application yields data before reading from the input, and

[Web-SIG] Prohibiting reading from wsgi.input in an application iterable's close method

2008-01-30 Thread Brian Smith
I would like to see the following requirement added to the WSGI specification: An application may only methods on environ[wsgi.input] before it returns its response iterable, or from within an execution of its iterable's next() method. In particular, the application iterable's close() method,

Re: [Web-SIG] Prototype of wsgi.input.readline().

2008-01-30 Thread Graham Dumpleton
On 31/01/2008, Chris McDonough [EMAIL PROTECTED] wrote: Graham Dumpleton wrote: As I think we all know, no one implements readline() for wsgi.input as defined in the WSGI specification. The reason for this is that stuff like cgi.FieldStorage would refuse to work and would just generate an

Re: [Web-SIG] Prototype of wsgi.input.readline().

2008-01-30 Thread Chris McDonough
Graham Dumpleton wrote: If the size argument is made mandatory, then it would parallel how read() function is defined, but this in itself would mean cgi.FieldStorage would break. This is because cgi.FieldStorage actually calls readline() with no argument as well as an argument in

Re: [Web-SIG] Prototype of wsgi.input.readline().

2008-01-30 Thread Graham Dumpleton
On 31/01/2008, Chris McDonough [EMAIL PROTECTED] wrote: Graham Dumpleton wrote: If the size argument is made mandatory, then it would parallel how read() function is defined, but this in itself would mean cgi.FieldStorage would break. This is because cgi.FieldStorage actually calls

Re: [Web-SIG] Prototype of wsgi.input.readline().

2008-01-30 Thread Chris McDonough
Graham Dumpleton wrote: On 31/01/2008, Chris McDonough [EMAIL PROTECTED] wrote: Graham Dumpleton wrote: If the size argument is made mandatory, then it would parallel how read() function is defined, but this in itself would mean cgi.FieldStorage would break. This is because cgi.FieldStorage

Re: [Web-SIG] Reading of input after headers sent and 100-continue.

2008-01-30 Thread Brian Smith
Graham Dumpleton wrote: Effectively, if a 200 response came back, it seems to suggest that the client still should send the request body, just that it 'SHOULD NOT wait for an indefinite period'. It doesn't say explicitly for the client that it shouldn't still send the request body if

Re: [Web-SIG] Reading of input after headers sent and 100-continue.

2008-01-30 Thread Graham Dumpleton
For those on the Python web sig who might be thinking they missed part of the conversation, you have. This is the second half of a conversation started on Apache modules-dev list about Apache 100-continue processing. If interested, you can see the first half of the conversation at: