[hunchentoot-devel] Is there a better way?

[Hans Hübner]

A cheap workaround would be to use HTTP/1.0 (no persistent connection,
non Content-Length header required).  I lack the time to try this out
myself, but what you write seems like being indicative of a problem in
the chunked encoding.

If you can afford the main memory footage of the WAV data encoded as
octets, you could also just return the vector from your handler and
let Hunchentoot deal with setting the headers properly.

-Hans

On Wed, Aug 6, 2008 at 11:27, Kevin Raison <raison at chatsubo.net> wrote:
> Actually, let me add a correction to my last post  (too many browsers, hard
> to remember which one did what):
>
> On Windows, without setting the content length header explicitly, IE would
> play the WAV stream properly using iTunes as its helper application, while
> Firefox would only play part of the stream using Quicktime as its helper.
>
> Cheers.
> Kevin
>
>
> Kevin Raison wrote:
>>
>> 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
>>>
>> _______________________________________________
>> 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
>