Re: [Web-SIG] WSGI and long response header values

Title: RE: [Web-SIG] WSGI and long response header values James Y Knight wrote: > I don't see what's wrong with encoding with the 75-char > word-limit, separating "words" by spaces, *without* newlines. > If the server feels like folding a long line into two, it > can do so, but it's perfectly

Re: [Web-SIG] WSGI and long response header values

Title: RE: [Web-SIG] WSGI and long response header values James Y Knight wrote: > On Sep 8, 2006, at 7:22 PM, Robert Brewer wrote: > > Bah. I knew I forgot a constraint in there (the strings > > have to be encoded by the app). Personally, I think the > > "separate-by-spaces" cure is worse tha

Re: [Web-SIG] WSGI and long response header values

On Sep 8, 2006, at 7:22 PM, Robert Brewer wrote: > Bah. I knew I forgot a constraint in there (the strings have to be > encoded by the app). Personally, I think the "separate-by-spaces" > cure is worse than the disease. I also finally found the only other > discussion of this issue [1] and .

Re: [Web-SIG] WSGI and long response header values

At 06:31 PM 9/8/2006 -0500, Ian Bicking wrote: >Robert Brewer wrote: > > PEP 333 says: > > > > "Each header_value must not include any control characters, including > > carriage returns or linefeeds, either embedded or at the end. (These > > requirements are to minimize the complexity of any parsin

Re: [Web-SIG] WSGI and long response header values

Robert Brewer wrote: > PEP 333 says: > > "Each header_value must not include any control characters, including > carriage returns or linefeeds, either embedded or at the end. (These > requirements are to minimize the complexity of any parsing that must be > performed by servers, gateways, and i

Re: [Web-SIG] WSGI and long response header values

Title: RE: [Web-SIG] WSGI and long response header values Phillip J. Eby wrote: > Robert Brewer wrote: > >So in my reading of HTTP, some code somewhere should introduce newlines in > >longish, encoded response header values. I see three options: > > > >  1. Keep things as they are and disallo

Re: [Web-SIG] WSGI and long response header values

At 02:02 PM 9/8/2006 -0700, Robert Brewer wrote: >PEP 333 says: > >"Each header_value must not include any control characters, including >carriage returns or linefeeds, either embedded or at the end. (These >requirements are to minimize the complexity of any parsing that must be >performed by s

[Web-SIG] WSGI and long response header values

Title: WSGI and long response header values PEP 333 says: "Each header_value must not include any control characters, including carriage returns or linefeeds, either embedded or at the end. (These requirements are to minimize the complexity of any parsing that must be performed by servers, g

Re: [Web-SIG] WSGI: read method

Robert Brewer wrote: > > Hmm... I could also set CONTENT_LENGTH='1', and make .read(1) return the > > actual entire body, totally ignoring the size argument. Or make it > > '9', or whatever. That seems bad-clever, but maybe most workable > > with PEP 333? > > I'm getting lost on the phra

Re: [Web-SIG] WSGI: read method

Title: RE: [Web-SIG] WSGI: read method Ian Bicking wrote: > An issue I just realized (as Robert was bringing up these things), > is that I would like to be able to give input streams that don't > have a known length.  In particular, I want to be able to do this: > > input = environ['wsgi.inpu

[Web-SIG] WSGI: read method

An issue I just realized (as Robert was bringing up these things), is that I would like to be able to give input streams that don't have a known length. In particular, I want to be able to do this: input = environ['wsgi.input'] if hasattr(input, 'json_request'): request = input.json_reques

[Web-SIG] WSGI and readline(size) support (was: WSGI type tolerance)

Title: WSGI and readline(size) support (was: WSGI type tolerance) Phillip J. Eby wrote: > Oops.  I just noticed that the ticket was about > response headers, not CGI variables. > ... > I'll add: > """Each ``header_name`` and ``header_value`` **must** be of StringType.""" Great! Thanks very m

Re: [Web-SIG] WSGI type tolerance

At 11:56 AM 9/8/2006 -0400, Phillip J. Eby wrote: >I'll change the phrasing of this: > >"""The environ dictionary is required to contain these CGI environment >variables, as defined by the Common Gateway Interface specification.""" > >to: > >"""The environ dictionary is required to contain these CG

Re: [Web-SIG] WSGI type tolerance

At 12:33 AM 9/8/2006 -0700, Robert Brewer wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="_=_NextPart_001_01C6D319.11101680" > >See >http://www.cherrypy.org/ticket/561. >Apparently, "several WSGI

[Web-SIG] WSGI type tolerance

Title: WSGI type tolerance See http://www.cherrypy.org/ticket/561. Apparently, "several WSGI apps" return an int for the Content-Length header. PEP 333 leaves just enough unsaid that someone might determine that's OK. But wsgiref and paste.lint certainly seem to think header values must be st