Why are requests always 404?

This time we will talk about something about 404. Because in the background of the public account and the QQ group, people are asking the same question:

My application has been deployed, and I haven’t seen any abnormal output when starting it in the background. You can request Tomcat's manager, but why does requesting your own application always return 404?

　Yeah, why is this?

　Let's analyze the description of this problem.

　1. The application is deployed and there is no abnormal output in the background.

　 2. Tomcat’s manager application can make normal requests

　 The above two points can only show that Tomcat starts normally, and the manager application and the user’s application are successfully deployed, but the manager’s request is normal, which does not guarantee that your own application will also be normal. ask.

After all, what your in-app resources are has nothing to do with the manager, and the address may even be wrong when you request it. In other words, you are watching the application deployed in the webapps directory, but requests in the browser always return 404 without stopping.

　The above question is the main analysis content of our article. Let’s first look at the status code of the HTTP request 404, which is described in Wikipedia:

　The HTTP error message 404 (Not Found) is a standard response code. In computer network communication, it indicates that the client can communicate with the server, but The server cannot find the resource requested by the client.

In Tomcat, 404 will be returned in many situations.

　We mentioned in the previous article that Tomcat contains two default Servlets:

　JspServlet, DefaultServlet. (How does Tomcat respond to static resources?)

　When we randomly request a resource that does not exist in Tomcat, such as the following two resources that do not exist:

　http://localhost:8080/abc and http:// localhost:8080/abcd.jsp

At this time, the two Servlets mentioned above will be requested. At this time, since the resource does not exist, the return 404 is consistent with our expectations.

For example, DefaultServlet, when processing a request, will check whether the currently requested resource exists in Resource.

A cache is used here to record all the resource content of the current application,

cannot be found in the resources. The picture below shows the resources within the Tomcat root application

After setting the status and message in the response here, the entire processing process ends. The display of the error page is based on the specific configuration. Different status codes can correspond to different page, here is the Tomcat error page, we have analyzed the specific implementation in the previous article. (Your error page. No, it’s your error page)

Let’s analyze another situation:

For example, when you request the manager application, the application name is written as Manager or manageR. At this time, the process is actually the same as the above. Consistently, this application name will be recognized as a resource of this application for processing, so if there is no such resource, 404 will naturally be returned.

　Look at another situation:

　There is an error page 404.jsp under the manager application, but if you directly request it in the following form, you will still get 404

　http://localhost:8080/manager/WEB -INF/jsp/404.jsp

Everyone knows that this is a restriction on directory access in Tomcat. (How much do you know about the WEB-INF directory)
Let’s look at another one:
A certain page in your application, assuming it is in index.jsp, essentially jumps to another page. If you use sendRedirect, it’s okay. Specific path information will be displayed after transfer. But assuming forward is used, at this time, the page you forward does not exist. At this time, every request will be 404, but you see that the page you requested is clearly lying quietly in the directory.

So, when you see a request returning 404, you need to analyze the situation on a case-by-case basis to determine the specific cause, whether it is really that the resource cannot be found, or other reasons.

It is even possible that you have configured multiple error codes corresponding to the same 404 error page. Every time you see 404, there may be other reasons.