It's required by the JSON-RPC spec as well, so I suppose it would be just as well to reject all requests that may get though without the header being set. I'll just do that.
I was pretty surprised by wsgi.input being a blocking read, though. I initially thought that it was deliberately set that way to support chunked encoding and long-lived connections (for things like Nevow LivePage, Comet, and other forms of "client push"). But I don't know what sense that makes in an HTTP 1.0 request. Rick Philip Jenvey wrote: > What clients do you know of do not properly set the Content-Length > header? It's required by the HTTP RFC. There's an alternative to > using Content-Length -- chunked encoding -- but that's only supported > by HTTP 1.1 servers (whereas currently paste httpserver is 1.0). > > Technically paste httpserver should be sending back a 411 code > (Content Length Required) if one isn't set, but I'm not sure if it does. > > -- > Philip Jenvey --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss -~----------~----~----~----~------~----~------~--~---
