SBCL simple-stream-error when serving audio file with ningle + clack.handler.hunchentoot

[resttime]

I'm not sure how I can handle this error properly. The source code in clack.handler.hunchentoot shows that the error should be ignored from what I understand, but I still receive it with the latest Clack from Quicklisp.

I'm using ningle to serve an audio file on the server on a route. The error happens once the user opens the audio file and again if the tab closes before it's done downloading/buffering. Which I believe is normal, but I'd like this to be ignorable so I can debug in SLIME without being interrupted by the error.

I'd like to keep the debug option but I'm clueless as to how to ignore the error. Sorry if I happen to be overlooking a very obvious solution.

debugger invoked on a SB-INT:SIMPLE-STREAM-ERROR in thread
#<THREAD "hunchentoot-worker-0000000000" RUNNING {1002D02EF3}>:
  Couldn't write to #<SB-SYS:FD-STREAM
                      for "socket ------------:-----, peer: ------------:------"
                      {1002D01C83}>:
    Connection reset by peer

[fukamachi]

Hmm. I could reproduce it on my machine, but I can't get why this happens. And, weirdly, it happens even when :debug nil. Is it getting thorough HANDLER-CASE even though the error inherits CL:ERROR?

[resttime]

My guess is that the error goes through somewhere else unhandled. Another guess is that it's related to new threads that Hunchentoot makes.

[resttime]

I believe that the problem has conveniently resolved itself with the latest versions of software. The error is displayed as intended and the SLIME debugger does not seem to be invoked anymore. I think this issue can be closed if you can confirm.

[2015-06-29 03:13:04 [ERROR]] 
Error while processing connection: couldn't read from #<SB-SYS:FD-STREAM 
for "socket x.x.x.x:xxxxx, peer: x.x.x.x:xxxxxx" {1002F6F2F3}>: Connection reset by peer

[fukamachi]

Thank you for letting me know. I'm closing this. Feel free to reopen it if anyone still has the same issue.

[blasut]

I'm having the same problem, when doing a POST request. Just a regular POST, when debugging I found that sending an empty POST requests, without any values it works just fine.

But with any kind of value, I've tried:

• Radio button
• Hidden input
• Text input
• Password input
• I even tested "datetime".

Really weird, haven't found a solution yet.

[blasut]

I'm using the latest available SBCL via homebrew (1.2.13) on OS X 10.

GET requests works fine, but POSTs and PUTs doesn't work. If there are any values in with the request.

[blasut]

I tried using CCL, but same issue

Input timeout on #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/20) #xF641116>
   [Condition of type INPUT-TIMEOUT]

[blasut]

I tried using another server, the "wookie" web server and it's the same problem. Just created a new app, with caveman2's app creation and started it. No problem POSTing stuff.