[hunchentoot-devel] Is there a better way?

Kevin Raison raison at chatsubo.net
Wed Aug 6 16:16:29 UTC 2008


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 at 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 at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
> 



More information about the Tbnl-devel mailing list