Thanks for the response, Edi. I am using 0.15.7. I tried Hans' recommendation of converting the WAV data into octets and then having the handler return those octets. This seems to have fixed the issue.
Further analysis of the Safari-related problems revealed something else: it seems that when Safari calls its helper application (in this case, Quicktime), it hands the helper a URL and all relevant cookies. Quicktime then does a GET which does not succeed because it is sending the wrong User Agent string for its Hunchentoot session cookie. <sigh> I guess I'll switch to IP-based sessions.
Thanks to both of you for your help.
Cheers. Kevin
Edi Weitz wrote:
On Wed, 06 Aug 2008 09:16:29 -0700, Kevin Raison raison@chatsubo.net wrote:
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?
Which version of Hunchentoot are you using, dev or release? Have you checked that it actually does the right thing when sending chunked content? I would hope that it does, but with the dev version I'm less sure and even with the release version there's of course always a chance that there are bugs. Also, could it be that you get requests for partial content somewhere that aren't handled as expected?
Edi (on vacation). _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel