Thanks for the response, Hans. To explain, I added the explicit content length header after seeing some strange and inconsistent behavior with browsers across several platforms. On the Mac using Firefox, the entire WAV stream would not reach the browser, so users would only hear part of their audio file. With Safari, the stream would not play at all. On Windows, IE behaved like Firefox on the Mac, but Firefox on Windows would not play the WAV stream at all. On Linux using Firefox, the browser would generally crash mid-way through the stream downloading. Opera on Linux worked fine. Explicitly adding the content length header solved all of these issues. Any ideas?
Thanks, Kevin
Hans Hübner wrote:
Kevin,
why do you feel that you need to set the content length explictly? By default, SEND-HEADERS returns a chunked stream, so setting the content length is not required. My suggestion is to keep using SEND-HEADERS and let the base64 decoder write to the stream. There is nothing wrong with your approach, except for the content length setting, which seems wasteful.
-Hans
On Tue, Aug 5, 2008 at 22:25, Kevin Raison raison@chatsubo.net wrote:
I am trying to determine the best way to accomplish the following task and could use some help. I am writing a web-based (using hunchentoot, of course) application for managing voicemail that is stored in Cisco's Unity system. I can access the voicemail box of a given use via IMAP. The mel project has helped make that part easy. However, I am not sure the best way to send the audio stream to the user's browser. The method below illustrates (inefficiently) what I need to do. Can anyone suggest a more efficient method that does not use (send-headers)? The hunchentoot docs say, "If your handlers return the full body as a string or as an array of octets, you should not call this function." However, I cannot find an alternative way to do what I need to do. I must fetch the voicemail as an email via IMAP and then decode the base64-encoded body, which contains the voicemail as a wav file. Writing out a wav file and pointing the user's browser to it would introduce security issues, so I must do this entire process in memory. Any help is appreciated.
(defmethod send-audio-stream ((user user) msg-id) "Convert the message body and send the wav content to the user." (handler-case (let ((msg (mel:find-message (mbox user) msg-id))) (setf (content-type) "audio/x-wav") (setf (header-out "Content-Disposition") (format t "inline; filename=~a.wav" msg-id)) (setf (content-length) ;; FIXME! Why do this twice? (length (base64-decode-msg-body-to-array msg))) (let ((stream (send-headers))) (base64-decode-msg-body-to-stream msg :stream stream))) (error (condition) (format nil "Unable to play message: ~a" condition))))
Cheers. Kevin Raison _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel