On Thu, 6 Jan 2011, Alice Bevan–McGregor wrote:
:: Clear separation of narrative from rules to be followed. This allows
developers of both servers and applications to easily run through a
confomance check list.
+1
:: Isolation of examples and rationale to improve readability of the core
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome by incorporatingthe
most common (1%) of features most often relegated to middlewareor
functional helpers.
Note that nearly every application-friendly feature you add will
increase the burden on both
On 2011-01-07 01:08:42 -0800, chris.dent said:
... this particular goal [reduction of reimplementation / NIH] could
cover a large number of things from standardized query string
processing (maybe a good idea) to filters (which I've already expressed
reservations about).
So this goal seems
At 01:17 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome by
incorporatingthe most common (1%) of features most often
relegated to middlewareor functional helpers.
Note that nearly every
No, otherwise I'd totally go for the surrogateescape approach. Heck,
I'd still go for it if it were possible to write a surrogateescape
handler for 2.6, and require that a PEP 444 server register one with
Python's codec system. I don't know if it's *possible*, though,
hopefully someone
At 01:22 PM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-07 08:28:15 -0800, P.J. Eby said:
At 01:17 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome
byincorporatingthe most common (1%) of
On 2011-01-07 20:34:09 -0800, P.J. Eby said:
That it [handling generators] is difficult at all means removes
degree-of-difficulty as a strong motivation to switch.
Agreed. I will be following up with a more concrete idea (including
p-code) to better describe what is currently in my brain.
On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote:
:: Making optional (and thus rarely-implemented) features non-optional. E.g.
server support for HTTP/1.1 with clarifications for interfacing applications
to 1.1 servers. Thus pipelining, chunked encoding, et. al. as per the HTTP
1.1
On 2011-01-06 13:06:36 -0800, James Y Knight said:
On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote:
:: Making optional (and thus rarely-implemented) features non-optional.
E.g. server support for HTTP/1.1 with clarifications for interfacing
applications to 1.1 servers. Thus
On Jan 6, 2011, at 4:56 PM, Alice Bevan–McGregor wrote:
On 2011-01-06 13:06:36 -0800, James Y Knight said:
On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote:
:: Making optional (and thus rarely-implemented) features non-optional.
E.g. server support for HTTP/1.1 with clarifications
One other comment about HTTP/1.1 features.
You will always be battling to have some HTTP/1.1 features work in a
controllable way. This is because WSGI gateways/adapters aren't often
directly interfacing with the raw HTTP layer, but with FASTCGI, SCGI,
AJP, CGI etc. In this sort of situation you
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
You will always be battling to have some HTTP/1.1 features work in a
controllable way. This is because WSGI gateways/adapters aren't often
directly interfacing with the raw HTTP layer, but with FASTCGI,
2011/1/7 Alex Grönholm alex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
You will always be battling to have some HTTP/1.1 features work in a
controllable way. This is because WSGI gateways/adapters aren't often
directly
2011/1/7 Graham Dumpleton graham.dumple...@gmail.com:
2011/1/7 Alex Grönholm alex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
You will always be battling to have some HTTP/1.1 features work in a
controllable way. This is
07.01.2011 04:09, Graham Dumpleton kirjoitti:
2011/1/7 Graham Dumpletongraham.dumple...@gmail.com:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
You will always be battling to have some HTTP/1.1
2011/1/7 Alex Grönholm alex.gronh...@nextday.fi:
07.01.2011 04:09, Graham Dumpleton kirjoitti:
2011/1/7 Graham Dumpletongraham.dumple...@gmail.com:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
On Jan 6, 2011, at 7:46 PM, Alex Grönholm wrote:
The WebDAV spec, on the other hand, says
(http://www.webdav.org/specs/rfc2518.html#STATUS_102):
The 102 (Processing) status code is an interim response used to inform the
client that the server has accepted the complete request, but has
2011/1/7 James Y Knight f...@fuhm.net:
On Jan 6, 2011, at 7:46 PM, Alex Grönholm wrote:
The WebDAV spec, on the other hand, says
(http://www.webdav.org/specs/rfc2518.html#STATUS_102):
The 102 (Processing) status code is an interim response used to inform the
client that the server has
07.01.2011 04:55, Graham Dumpleton kirjoitti:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 04:09, Graham Dumpleton kirjoitti:
2011/1/7 Graham Dumpletongraham.dumple...@gmail.com:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One
At 12:52 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Ignoring async for the moment, the goals of the PEP 444 rewrite are:
:: Clear separation of narrative from rules to be
followed. This allows developers of both servers and applications
to easily run through a confomance check list.
::
On 2011-01-06 14:14:32 -0800, Alice Bevan–McGregor said:
There was something, somewhere I was reading related to WSGI about
requiring content-length... but no matter.
Right, I remember now: the HTTP 1.0 specification. (Honestly not
trying to sound sarcastic!) See:
On Jan 7, 2011, at 12:13 AM, Alice Bevan–McGregor wrote:
On 2011-01-06 14:14:32 -0800, Alice Bevan–McGregor said:
There was something, somewhere I was reading related to WSGI about requiring
content-length... but no matter.
Right, I remember now: the HTTP 1.0 specification. (Honestly not
On 2011-01-06 21:26:32 -0800, James Y Knight said:
You've misread that section. In HTTP/1.0, *requests* were required to
have a Content-Length if they had a body (HTTP 1.1 fixed that with
chunked request support). Responses have never had that restriction:
they have always (even since before
23 matches
Mail list logo
