;
>
> Robert Brewer
> System Architect
> Amor Ministries
> [EMAIL PROTECTED]
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
> [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
> [3] http://www.rfc.net/rfc2047.html#s2
>
> ____
Now in English:
My reading of WSGI was that implementations should already be folding
multi-line headers.
Cheers,
On 2006/09/09, at 5:18 PM, Mark Nottingham wrote:
> My reading o WSGI was that multi-line headers should already be
> folding multi-line headers. If that's the case,
already occurred before any data was read.
>
> So, what gives. What should a WSGI server do for chunked transfer
> encoding on
> a request?
>
> I may not totally understand 100 continue and chunked transfer
> encoding and
> am happy to be correct in my underst
; 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/mnot%
> 40mnot.net
--
Mark Nottingham http://www.mnot.net/
___
Web-SIG mailing list
Web
ly crash. It is
WSGI-like, but not WSGI compatible, because there were a few places
where WSGI was too constraining. However, it may be useful as food for
thought in API revisions. Or not. :)
Cheers,
--
Mark Nottingham http://www.mnot.net/
___
W
at at the bottoms of src/client.py and src/server.py, as well as
scripts/proxy.py.
Cheers,
On 17/06/2009, at 9:49 AM, Graham Dumpleton wrote:
2009/6/17 Mark Nottingham :
I've recently put up a library that I've been working on for a
little while,
nbhttp:
<http://github.com/mno
ta, because you can't
be certain of their encoding unless you have knowledge of the header.
On 21/09/2009, at 12:50 AM, Armin Ronacher wrote:
Also (something I haven't yet filed as a bug because I guess there
will
be more changes involved) the HTTP server in Python 3.1 does not
su
to make everyone need to change their routing code on
Python 3, I vote +1000. ;-)
___
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/mnot%40mnot.net
--
Mark Nottingham http://www.mnot.
days. Most things
layered on top of wsgi are using utf-8 (django etc), and lots of web
clients are using utf-8 (firefox etc).
Why not move to unicode?
--
Mark Nottingham http://www.mnot.net/
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG:
Reference?
On 22/09/2009, at 12:07 PM, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham :
Most things is not the Web. How will you handle serving images
through WSGI?
Compressed content? PDFs?
You are perhaps misunderstanding something. A WSGI application still
should return bytes
On 22/09/2009, at 12:26 PM, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham :
Reference?
See:
http://blog.dscpl.com.au/2009/09/roadmap-for-python-wsgi-specification.html
Anyone else jumping in on this conversation with their own opinions
and who has not read it, should perhaps at least
ences", as per PEP 333?
Cheers,
On 22/09/2009, at 4:07 PM, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham :
OK, that's quite exhaustive.
For the benefit of those of us jumping in, could you summarise your
proposal
in something like the following manner:
1. How the request
) bar to
entry for the discussion.
Thanks,
On 22/09/2009, at 4:36 PM, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham :
So, what advice do you propose about decoding bytes into strings
for the
request-URI / method / request headers, and vice versa for response
headers
and status code/p
should not obscure the proposal itself.
I'm not sure how to take your "ticket monkeys" comment, so I'll ignore
it.
On 22/09/2009, at 4:44 PM, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham :
That blog entry is eleven printed pages. Given that PEP 333 also
prints as
2009/9/22 Mark Nottingham :
You're twisting my words; nowhere did I say i wasn't willing to
read the
PEP. What I did say was that a proposal can and should be made in
less than
eleven pages; I'd like to give my feedback, both because I use
Python and
because I have some inte
On 22/09/2009, at 6:11 PM, Armin Ronacher wrote:
Hi,
Mark Nottingham schrieb:
HTTP headers *are* ASCII; RFC2616 defined them to be ISO-8859-1, but
HTTPbis currently takes the stance that they're ASCII, as in practice
Latin-1 isn't used and may introduce interop problems.
In pr
16 matches
Mail list logo