On Wed, Mar 16, 2011 at 3:33 AM, tsuraan <[email protected]> wrote:
> Pasted at the bottom, both with and without POST data.  Where it goes
> from 10 to 9, with the "timeoutThread: woke up", it seemed to want to
> do that forever until I killed curl.  At that point, snap went from 9
> to 10, and then 10 to 9, and then stopped printing.  GET works fine,
> but if you want a printout of that, I can send it as well.

OK, this looks like a Curl bug. If you'll notice:

> [      10] SimpleBackend.enumerate(8): sending "POST /echo/hi
> HTTP/1.1\r\nUser-Agent: curl/7.20.0 (x86_64-pc-linux-gnu)
> libcurl/7.20.0 OpenSSL/0.9.8n zlib/1.2.3\r\nHost:
> localhost:8000\r\nAccept: */*\r\n\r\n" to continuation
> [      10] receiveRequest/setEnumerator: request did NOT have content-length

From the HTTP/1.0 spec:

> A valid Content-Length is required on all HTTP/1.0 POST requests. An HTTP/1.0 
> server should respond with a 400 (bad request) message if it cannot determine 
> the length of the request message's content.

From the HTTP/1.1 spec:

> If a request contains a message-body and a Content-Length is not given, the 
> server SHOULD respond with 400 (bad request) if it cannot determine the 
> length of the message, or with 411 (length required) if it wishes to insist 
> on receiving a valid Content-Length.

Also from the HTTP/1.1 spec:

> When a message-body is included with a message, the transfer-length of that 
> body is determined by one of the following (in order of precedence):
> ...
> 5. By the server closing the connection. (Closing the connection cannot be 
> used to indicate the end of a request body, since that would leave no 
> possibility for the server to send back a response.)

So Curl is out-of-spec here. However, we should be sending back a 411
response instead of trying to read a request body which will never
come. Please open a bug on
http://github.com/snapframework/snap-core/issues.


> As an aside, and totally off-topic, it seems like whenever I do a
> cabal update, I wind up having to wipe out my entire ~/.ghc and
> ~/.cabal and begin from scratch, because half my modules rely on some
> old version of an updated module, which doesn't exist anymore, and
> everything's all hosed.  Is that normal?

Are you sure you're doing "cabal update" and not "cabal upgrade"?
Upgrade is completely broken and you shouldn't use it.

G
-- 
Gregory Collins <[email protected]>
_______________________________________________
Snap mailing list
[email protected]
http://mailman-mail5.webfaction.com/listinfo/snap

Reply via email to