HTTP Streaming WAV audio no longer works with quicktime 7.7.3 OSX or 7.7.5 in windows

Question

The latest revisions of quicktime (as plugin) no longer play our webservice's streamed audio files.  The audio is simply encoded wav all javascript hooks seem to work properly, but there is no resulting audio output. Reverting to previous revisions of quicktime on the same platforms restores the expected behavior.
The files are streamed over authenticated HTTPS connections and are encoded as "RIFF (little-endian) data, WAVE audio, ITU G.711 mu-law, stereo 8000 Hz".  If the file is downloaded to the local machine, the quicktime player application has no problems playing the audio.  Similarly, dropping a file: URL to the download into the web browser also plays correctly. The issue started with Quicktime 7.7.3 on OSX with Safari (Yosemite) and 7.7.5 on Windows (Chrome and Firefox). Mavericks and previous Windows quicktime plugins work correctly.  This is especially problematic for our Mac OS clients because we have not been able to identify a current working combination or a functional downgrade path other than to downgrade the OS to Mavericks.
Any suggestions or guidance would be greatly appreciated.
Thanks!

Answer 1

Jon, I read.  But the links to websites are not playing on a Windows7 computer. Can you tell me why they are not?
I believe that with a new dawn comes new understanding of the problem.
I do not have access to a Windows 7 computer nor do I run Windows on my Mac.
I am not a web coding programmer. However...
Neither of the original poster's links (http://openmap.bbn.com/~mthome/quicktimeaudio.html and http://openmap.bbn.com/~mthome/wavtest.wav) work because they both point to the same HTML (quicktimeaudio.html) file.
The HTML file looks like this:
This file appears to look for the QT plug-in to see if QT is installed, if the version is v7.7.6, and whether or not the WAV extension is supported.
When I click on either link, this is what I see:
Although I am running:
the browser display shown above indicates the HTML code thinks that QT is not installed rather than being the wrong version and then, instead of terminating the browser processing and displaying the correct error message, the HTML code falls through to a display of the audio media controller and automatically starts playback. Unfortunately, since confirmation of WAV playback support was skipped (or for some other reason), the QT plug-in does not access the required codec (or fails to send the data to the handler) and no audio is heard when playing the WAV audio file. In short, even though I am not a web programmer, I believe the main issue here is the coding of the HTML file.
When I "re-containered" the original poster's WAV file and posted it on my own server, I created a URL link that actually pointed to the WAV resource and not to the HTML file code as did the OP's secondary link. Thus, when I accessed the audio file, I did so directly via the plug-in, by-passing the HTML file code issue and allowing the file data to play correctly in Safari under both Yosemite and IOS 8.
Believe the HTML file needs to be re-coded to fix the problem. I can now play the original 8-bit µ-law encoded WAV file in players and Safari but believe the OP here should consider a more modern compression format/file container combination that would allow him to abandon use of the QT player plug-in to maintain compatibility with "plug-in free" browsers. For instance, would HTML5 coding be able to play AAC encoded content in MOV, MP4, M4V, and/or M4A file containers? Once again, questions like this are beyond my expertise and need to be answered by someone proficient in this area.