[Zope-dev] ZServer HTTP 1.1 support

[Jamie Heilman]

Paul Winkler wrote:
> I noticed this in ZServer/README.txt (zope 2.6.2):
> 
> HTTP 1.1 support is ZServer is incomplete, though it should work for
>     most HTTP 1.1 clients.
> 
> Anybody know what specifically is "incomplete"?

A lot of stuff.  There's a also a good deal of just flat-out
brokenness.  HTTP/1.1 requests don't require a Host header in
violation of rfc2616.  ZServer responds with any arbitrary HTTP
version number which causes all kinds of pain when migrating between
new versions of the protocol.  As it stands if a client comes and asks
for HTTP/1.2 ZServer will respond with HTTP/1.2 which is bullshit
because it doesn't know how to speak HTTP/1.2 and assuming it does is
really dumb.  AFAICT it doesn't coalesce headers with the same field
name when the valus are comma-separated lists.  ZServer will
url-decode the entire request line, http version, method, all of it,
before logging, not actually a HTTP/1.1 bug... just a random bit of
stupidity I noticed.  ZServer responds completely wrong to HEAD
requests, we've all known about that one for ages.  ZServer tries to
swallow spurious CRLFs before the Request-Line but fails after two
because it triggers a stage change (really not a terribly crucial bug,
that ... I only mention it for completeness).  ZServer doesn't look
for message bodies when a Transfer-Encoding header is present, which
violates all kinds of rules about the collection of message bodies.
Treats HTTP/0.9 as HTTP/1.0, etc, etc, etc.  The list goes on and on.
None of which is a particularly big deal as long as you use a
production quality gateway server that does its best to forward santized
requests in front of ZServer.
 
> In particular, some people on my team asked me if zserver
> supports "persistent" connections, and I didn't know how
> to answer. I'm looking now at HTTPServer.py and the docstrings
> suggest that it does ... yes? no?

To a fault.  HTTP/1.1 requests will remain open (unless configured
otherwise) for something like a half an hour IIRC, but the trigger to
close them is another incoming request, which means on a quiet
interface you can keep a single connection alive essentially forever
(should you want to do that).  Of course if you're keeping an HTTP
session alive that long you're probably doing something completely
sick and wrong and would be better off using a protocol more suited
for long running task execution.

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/
"Most people wouldn't know music if it came up and bit them on the ass."
                                                        -Frank Zappa