Hi Paul, I cannot answer Your original question:

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"?

but instead a complete random off remark:

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?

You can try out yourself: connect to the Zope server via "telnet" and type in: """ GET / HTTP/1.1 Host: localhost """ The server should serve the page, and if it supports "persistent" connections, if should not close the connection, so You can type in the request again (if You type fast enough to finish before the timeout ;-) Cheers, Clemens

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

On Thursday 11 December 2003 21:39, Paul Winkler wrote:

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?

If you have a squid proxy in front of your zope, then squid will manange both HTTP 1.1 persistent connections to your browsers, and persistent connections to your Zope. The squid-to-zope persistent connections are not in the style of HTTP 1.1 though. Squid uses slightly different headers - I forget the details. -- Toby Dickenson