Hi, Yes, path is tomcat/webapps/ROOT/wav/
As I said earlier, 404 error is only returned 1st time. Subsequent requests work fine. On Tue, Mar 12, 2024, 3:13 a.m. Anson Cheung <xiaohuache...@gmail.com> wrote: > src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3" > Please confirm that your file is placed under the path > "..../apache-tomcat-9.0.30/webapps/ROOT/wav/" not " /wav/ " > > On Tue, Mar 12, 2024 at 11:20 AM Sam <maverick...@gmail.com> wrote: > > > Hi Chris, > > > > I'm creating the audio file dynamically from DB and I check if the file > > exists using File.exists() method. > > > > Before returning the html code with audio tag, I'm verifying that file > > exists on File System. > > > > Thanks! > > > > On Mon, Mar 11, 2024 at 2:36 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > > Sam, > > > > > > On 3/11/24 13:04, Sam wrote: > > > > On the server side, I'm checking that file exists before returning > the > > > file > > > > path to the browser. We are also dynamically creating pdf files this > > way > > > > and no issues with accessing them. > > > > > > How are you checking to see if the file exists? It's possible that your > > > check-for-existance triggers the "not found" in Tomcat's <Resources> > > > instance, then you create your file on-disk and return the path to the > > > browser, then the browser requests the path and gets the cached "not > > > found". > > > > > > > I found something interesting: > > > > https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html From > > this > > > > link: > > > > *Resources are cached by default.* > > > > > > > > I'll try with *Cache-Control* request header and see if it helps! > > > > > > This isn't likey to be the problem. I think the cache you are fighting > > > is the one Tomcat maintains for "resources" which is how Tomcat loads > > > things from ... well, everywhere. Not caching things like "not found" > > > makes things go very slowly. > > > > > > -chris > > > > > > > On Mon, Mar 11, 2024 at 11:46 AM Mark Thomas <ma...@apache.org> > wrote: > > > > > > > >> On 11/03/2024 11:31, Sam wrote: > > > >>> Thanks for replying!! > > > >>> > > > >>> Yes audio files are generated dynamically from DB.in a Servlet. > > > >>> > > > >>> I've verified that audio file exists on file system before > returning > > > the > > > >>> html code that contains audo control. > > > >> > > > >> Is there any chance of an attempt to access the file before it is > > > >> created? The resources implementation can cache "not found" results > > for > > > >> a short period of time. > > > >> > > > >> You might want to test the code with a simple text file to determine > > > >> whether file type is a factor (which seems unlikely but you never > > know). > > > >> > > > >> Mark > > > >> > > > >>> > > > >>> > > > >>> On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas <ma...@apache.org> > > wrote: > > > >>> > > > >>>> On 11/03/2024 02:21, Sam wrote: > > > >>>>> I just upgraded a legacy application from Tomcat 7 to Tomcat 9. > > It's > > > >>>>> deployed as a war file. I'm facing a weird issue with audio files > > > >>>> playback. > > > >>>>> > > > >>>>> When loading a page that contains an audio file. First time > Tomcat > > > >>>> returns > > > >>>>> 404 error but if reloading the page, audio file is loaded > properly > > > and > > > >> no > > > >>>>> error from Tomcat. > > > >>>>> > > > >>>>> I'm using html 5 audio control to display the file. > > > >>>>> > > > >>>>> All other static resources(images, css and js files) are working > > > >> without > > > >>>>> any issues. Only audio files are having this issue. > > > >>>>> > > > >>>>> I enabled the logs for DefaultServlet in Tomcat. Follwong is the > > log > > > >>>> entry > > > >>>>> when I try to open the audio file first time. I can see 404 being > > > >>>> returned > > > >>>>> from server in Chrome dev tools. > > > >>>>> > > > >>>>> > > > >>>>> *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: > > Serving > > > >>>>> resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' > > headers > > > >> and > > > >>>>> data* > > > >>>>> Following is the log for 2nd attempt. This time audio is > available > > > and > > > >>>>> playable in browser. *09-Mar-2024 20:13:00.371 INFO > > > >>>>> DefaultServlet.serveResource: Serving resource > > > >>>>> '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and > > data > > > * > > > >>>>> *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile: > > > >>>>> contentType='audio/mpeg'* > > > >>>> > > > >>>> Are the audio files generated dynamically on request? > > > >>>> > > > >>>> Mark > > > >>>> > > > >>>> > > > >>>>> > > > >>>>> Here is the audio control code: > > > >>>>> > > > >>>>> <div id="audioContainer" style="height:65px; width:100%; > > > >>>>> visibility:visible; "> > > > >>>>> <div id="jobAudio" style="height:45px; width: 100%; > left:0px; > > > >>>> bottom:0;" > > > >>>>>> > > > >>>>> <audio controls controlsList="nodownload" style="width: > > > 100%;" > > > >>> > > > >>>>> <source > > > >> src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3" > > > >>>>> type="audio/mpeg" > > > > >>>>> </audio> > > > >>>>> </div> > > > >>>>> </div> > > > >>>>> I've tried relative path and full path but result is the same in > > both > > > >>>> cases. > > > >>>>> > > > >>>>> I've spent days trying to solve this but no luck :( > > > >>>>> > > > >>>>> I would really appreciate any guidance to solve this issue. > > > >>>>> > > > >>>>> Thanks! > > > >>>>> > > > >>>> > > > >>>> > > --------------------------------------------------------------------- > > > >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > >>>> For additional commands, e-mail: users-h...@tomcat.apache.org > > > >>>> > > > >>>> > > > >>> > > > >> > > > >> > --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > >> > > > >> > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > >
