New Images (on Windows) Receive 404 Response from Tomcat - windows

SOLUTION: Reinstalled Tomcat. I must admit that I didn't solve the details of this problem. Something went wrong. Eventually, it looked like something with the server wasn't working. I never figured it out. But reinstalling the server (actually I upgraded to v9) got it working properly again.
UPDATE: Made a copy of the ROOT directory (Tomcat webapps) and the copy works fine. Then I changed the name of ROOT to a backup and the name of the copy to ROOT. The problem exists with the copy.
Windows 7 Tomcat 8 Java 8
To be honest, I need a hint. I've been running a web shop for several years. Now suddenly I'm getting 404 responses from Tomcat on new images. The images are in the same folders as they have been all along. The most recent test was to simply copy-paste an existing image (which Tomcat serves properly) in the folder and rename it. Tomcat responds with 404 on the copy (but not the original).
I've checked permissions on the image files. The folder has more than 7K images (NTFS) - in theory, that shouldn't be a problem. Just to be sure, I deleted a dozen that were out of date. No change. I ran chkdsk and used a second disk analyzer just in case. The images can be viewed with Microsoft photo-viewer and Paint. I've even save-replaced with Paint - no change. I've tried clearing browser caches and even Tomcat's cache (which doesn't seem to contain images) and set Resources cachingAllowed="false" within the Context tag (context.xml) It seems that my final simple test says everything I know about the problem at this point. Tomcat returns 404 on new images.
Note: Testing is not being done through the web shop software. I simply type the web address of the image in the browser address bar. It's then just a matter of Tomcat serving the image. There are no differences in the addresses except for the image file names.
UPDATE: Ran Malwarebytes ... no evidence of malware at this point. Running Panda full-time.

Related

HTTP 403.14 - Forbidden when endpoint is /tests/

I have an ASP.Net Core app with the usual default routing set up in Startup.cs. My app has a TestsController, with some action routines, including an Index() routine.
I've never had a problem navigating to my app's /tests/ or /tests/index endpoints before today. As of today, attempting to navigate to /tests gives me the IIS HTTP Error 403.14 - Forbidden error page. If I try to navigate to /tests/index then I get the IIS HTTP Error 404.0 - Not Found page.
All of the other endpoints in my app seem to work correctly. It's just the /tests endpoints that fail.
If I rename the controller from TestsController to TestController (remove the "s") then I have no problem navigating to either /test or /test/index.
So, this smells like IIS is maybe finding a Tests folder that it thinks I'm trying to list? But the only Tests folder I can see in Windows Explorer is in the obj\Debug\netcoreapp2.2\Razor\Views folder. I don't think IIS is tripping over that.
One other data point: Yesterday, I ran into a weird problem where VS 2019 would load my project and immediately complain that "A process used by VS has encountered an unrecoverable error". I eventually figured out that this was caused (for some unknown reason) by the presence of a tag helper I was working on. Removing the tag helper code fixed that problem. But it's suspicious that now I have this new problem. On the presumption that the tag helper problem left some detritus behind, I deleted all of the bin and obj folders, deleted all of the NuGet packages, rebooted (a couple of times) and rebuilt everything. No luck, I still can't navigate to the /tests endpoint.
EDIT: Another data point: I just tried the same code on another machine, and it works correctly. The problem is isolated to the one machine.
How do I ask IIS where it thinks it's finding a tests folder?
Not terribly helpful answer, but it's what I've got... I spent a frustrating week with MS tech support, with no resolution. In the end, I nuked the local repo and re-cloned it, and the problem went away.
It was really weird. If I simply renamed the parent directory for the solution and all of its projects then the problem went away. If I renamed the directory back to its original name then the problem came back.

ClickOnce Error "different computed hash than specified in manifest" when transferring published files

I am in an interesting situation where I maintain the code for a program that is used and distributed primarily by our sister company. We are ready to distribute the program to all of the 3rd party users and since it is technically our sister companies program, we want to host it on their website. (in the interest of anonimity, I'll use 'program' everywhere instead of the actual application name, and 'www.SisterCompany.com' instead of their actual URL.)
So I get everything ready to go, setup the Publish setting to check for updates at program start, the minimum required version, and I set the Insallation Folder URL and Update Location to "http://www.SisterCompany.com/apps/program/", with the actual Publishing Folder Location as "C:\LocalProjects\Program\Publish\". Everything else is pretty standard.
After publish, I confirm that everything installs and works correctly when running directly from the publish location on my C: drive. So I put everything on our FTP server, and the guy at our sister company pulls it down and places everything in the '/apps/program/' directory on their webserver.
This is where it goes bad. When I try to install it from their site, I get the - File, Program.exe.config, has a different computed hash than specified in manifest. Error. I tested it a bit, and I even get that error trying to install from any network location on our network other than my local C: drive.
After doing the initial publish in visual studio, I have changed no files (which is the answer/reason I've found by doing some searching about this error).
What could be causing this? Is it because I set the Installation Folder URL to a location that it isn't initially published too?
Let me know if any additional info is needed.
Thanks.
After bashing my head against this all weekend, I have finally found the answer. After unsigning the project and removing the hash on the offending file (an xml file), I got the program to install, but it was giving me 'Windows Side by Side' Errors. I drilled down into the App Cache were the file was, and instead of a config .xml file, it was one of the HTML files from the website the clickonce installer was hosted on. Turns out that the web server didn't seem to like serving up an .XML (or .mdb it turns out) file.
This MSDN article ended up giving me the final solution:
I had to make sure that the 'Use ".deploy" file extension' was selected so that the web server wouldn't mangle files with extensions it didn't like.
I couldn't figure out why that one file's hash would be different. Turns out it wasn't even the same file at all.
It is possible that one of the FTP transfers is happening in text mode, rather than binary?
For me the problem was that .config transformations were done after generating manifest.
To anyone else who's still having trouble, five years later:
The first problem was configuring the MIME type, which on nginx (/etc/nginx/mime.types) should look like this:
application/x-ms-manifest application
See Click Once Server and Client Configuration.
The weirder problem to me was that I was using git to handle the push to the server, i.e.
git remote add live ssh://user#mybox/path/to/publish
git commit -am "committing...";git push live master
Works great for most things, but it was probably being registered as a "change," which prevented the app from installing locally. Once I started using scp instead:
scp -r * user#mybox/path/to/dir/
It worked without a hitch.
It is unfortunate that there is not a lot of helpful information out there about this.

Filezilla not updating files

I made a modification in a php file and uploaded it via Filezilla. It always worked fine for me, even if sometimes it would not upload immediately. This time, however, it's not working anymore in any way. I upload the file with the same name and it looks like it overwrites the old one, but the size of the file doesn't change. When I open the site on the browser (I've been testing in Chrome and Firefox and already cleaned their caches many times since then, and still nothing happens) and look at the source code, it shows the new code with the modification, but even so the site is still the same old one. When I open the file directly from Filezilla it also shows the modified file, but the file size doesn't change. It started yesterday, before the upgrading to version 3.7.3. It's updated now, but the files are still not being updated. I also tried renaming the file, deleting it from the ftp and uploading again, uploading it to another folder and then moving it to the root, but nothing happens. Any idea of what can be causing this?
It turns out it was a problem with the permissions with the host. I contacted them and the issue was solved.

Flex 4 with PHP and BulkLoader - Assets getting deleted

Has anyone ever encountered a situation where your assets (image png files) got deleted from your web path?
Let me explain it little more clearly.
I am loading some images located in my localhost (not in flex4 application path) from my flex4 application using the loader and also with BulkLoader
This is the second time it happened that some of the images got deleted from the path which are in localhost.
I am not sure what is causing this? is that the loader? or bulkloader or the webserver? (WAMP) or any virus?
It happened 2nd time in last 7 days. I was lucky that I had a copy in the remote host so I got them back easily. But its a mistrey what and why it is getting deleted.
Any thoughts what might have caused this? or anyone knows any bug in the Loader or BulkLoader?
Well I found the answer. The culprit is the Flash Builder.
I am prity sure many of flash developers have faced the debugger launching issue where the flash builder never launches the app as it might have struck up some where and it halts the launching process at around 50-60% progress. It happened to me too and happens considerable enough times in a day.
I just found that this is linked to the issue which I have asked.
FB cleans the debug/output folder every time the app is compiled. I wouldn't have mind if it cleans only the project files. However, it just removes all the contents in the folder and adds them back. This happens in the back ground every time I change the code and save and run or "Clean" the project to build a fresh copy.
During this process (removing and adding files back) if the FB struck up and I forcefully terminate the process (which is must some times); my files are gone.
The flash output folder is my web root where I will have all my php, assets and all server-side stuff.
I will open a topic to discuss on how to avoid it which also I have problem there too.

Moved website, now images broken

Unsure if this should be on here or serverfault so apologies if I'm wrong.
I just moved my site from one folder to another on my server (what happened was, I was doing an update, which didn't quite work, so I transferred all the old files back). Now all my images on the site are broken.
Does anyone know why this happens? Or how to fix it more importantly?
Any help/advice would be appreciated!
Thanks
EDIT:
Okay, apparently I need to make sure the code is compiled, but completely lost as to how to do this..any ideas?
I'm also on a windows 2008 server, running IIS7. The application is written in C# .net MVC.
It doesn't seems that you have a compilation problem since the aplication is working. I mean, if you can run the website, but you are only missing the images, try to look for the paths and check if the image files are in there.
For an MVC (C#) app you should have the directory like this:
root/global.asax
root/web.config
root/Views/..
root/Model/..
´root´ is gonna be your first public folder on the WebServer
Hope it helps!
Make sure the paths to your image files (and any files for that matter) are relative to the root directory of your web site. This way, if you ever move all of the files pertaining to your web site from one location to another, everything stays relative and nothing should be broken.

Resources