Error when an audio file is loaded from a HTML5 <audio> control #146
Comments
|
Is the problem the error message or is the content not properly delivered? |
|
The real problem is that this error occasionally totally locks down the web server so it has to be rebooted. I'm running it on Raspberry Pi as part of a bigger application and in this case the Pi cannot be accessed by ssh/Putty anymore. But the error is reproducible on Windows 7 and Ubuntu Linux, as well with CCL or SBCL and Chrome and Firefox. |
|
I'm annoyed by this message, too. This happens anytime the browser cancels loading a resource. I think Hunchentoot should just ignore write errors and close the connection if an error happens. |
|
I think it should be ignored too. |
|
This isn't a real solution. In order to ignore this error I am using an altered version of (defun handle-static-file (pathname &optional content-type callback)
"A function which acts like a Hunchentoot handler for the file
denoted by PATHNAME. Sends a content type header corresponding to
CONTENT-TYPE or \(if that is NIL) tries to determine the content type
via the suffix of the file.
CALLBACK is run just before sending the file, and can be used
to set headers or check authorization;
arguments are the filename and the (guessed) content-type."
(when (or (wild-pathname-p pathname)
(not (fad:file-exists-p pathname))
(fad:directory-exists-p pathname))
;; file does not exist
(setf (return-code*) +http-not-found+)
(abort-request-handler))
(unless content-type
(setf content-type (mime-type pathname)))
(let ((time (or (file-write-date pathname)
(get-universal-time)))
bytes-to-send)
(setf (content-type*) (or (and content-type
(maybe-add-charset-to-content-type-header content-type (reply-external-format*)))
"application/octet-stream")
(header-out :last-modified) (rfc-1123-date time)
(header-out :accept-ranges) "bytes")
(handle-if-modified-since time)
(unless (null callback)
(funcall callback pathname content-type))
(with-open-file (file pathname
:direction :input
:element-type 'octet)
(setf bytes-to-send (maybe-handle-range-header file)
(content-length*) bytes-to-send)
;; THIS IS THE HACKY PART
(handler-case
(let ((out (send-headers))
(buf (make-array +buffer-length+ :element-type 'octet)))
(loop
(when (zerop bytes-to-send)
(return))
(let* ((chunk-size (min +buffer-length+ bytes-to-send)))
(unless (eql chunk-size (read-sequence buf file :end chunk-size))
(error "can't read from input file"))
(write-sequence buf out :end chunk-size)
(decf bytes-to-send chunk-size)))
(finish-output out))
(error (e)
(format *error-output* "Caught error while sending static file: ~a~%" e)
nil))))) |
When a browser download data from a HTML5 control, an error is produced when writing to the TCP stream. The exact error message is different with different OS/CL versions but the error occurs
every time. I tested
Probably has to do with HTTP code 206 "partial content"
Getting the whole file with wget etc. works fine
To reproduce this error,
start your Lisp, load the following file web.lisp and type (run)
Point your browser to http://localhost:8080/music.html
and check ./message.log and ./access.log afterwards
Sample logs created with CCL under Ubuntu:
access.log:
message.log:
web.lisp:
music.html:
The text was updated successfully, but these errors were encountered: