How does web server differentiates between request for static web page and request for
dynamic web page?
I'm not sure but i think if web server receives request for static page directly renders that to server
or else if request is for dynamic web page passes that to web app which processes the request and
renders that to client. bUT how does web server differentiates between both the request.
Ultimately, every J2EE page is a "dynamic web page". Some are just more dynamic than others.
When a URL request comes in to a J2EE server, the server dissects the URL. For example: "http://www.javaranch.com/payroll/images/moose.png".
The protocol and server-related information (http://www.javaranch.com) is snipped off, leaving the Context URL: "/payroll/images/moose.png".
Then the server's list of Context patterns is scanned, looking for a match. This list is built as webapps are deployed and the Context name is either supplied as part of the server-specific deployment descriptor (for Tomcat, that's the "Context" element), or it is synthesized by default. Again, using Tomcat this name would be the name of the WAR dropped in the TOMCAT_HOME/webapps folder.
Having determined which webapp gets the URL request, the URL is further scanned for the URL resource path. Which would be "images/moose.png". At this stage, it's looking for a match against the list of "servlet-mapping" url-patterns.
If the webapp finds a servlet-mapping for "images", then the request is then sent to that servlet for processing. But if there is no servlet-mapping, there's a default servlet built into the J2EE server itself.
This default server will then take the URL resource path and break it down into a WAR resource path. This is the mechanism that makes people mistake web servers for file servers, since both URL paths and (Unix-style) filesystem paths look so similar. The HttpServletRequest "getResource" method and its related "getResourceAsStream" methods can be used to take a WAR resource path such as "/images/moose.png" and locate the WAR resource, which is either a discrete file/directory (for an "exploded" WAR) or a ZIPfile entry (for a standard WAR). The Default Servlet will check to see what the data type is of the located resource, and if it's a directory and options permit, it will run servlet code that produces a directory listing webpage. If it's a static resource such as a graphics file, that file is opened and its contents are copied to the HttpServletResponse outputStream. As part of the process, various headers such as Content-Type and Content-Length may be included in the response.
Oh yeah. JSPs. The URL scanning process also looks to see if the URL request matches a JSP's resource path. If so, the "compiled JSP" cache is searched to find the compiled code for that JSP, and since that code is a servlet, the URL request gets passed to the JSP's servlet. If it's not in the cache, the JSP is run through a JSP compiler process, which often results in Java servlet class source, passed through the Java compiler, and then the results go into the cache. At which point, the processing is the same as a previously-cached JSP would have.
An IDE is no substitute for an Intelligent Developer.
I was referring to the JSP one. I was kind of curious (because I've never thought about it until now) why it's needed . . . does the *.jsp file name not signal to the server that this is a JSP? So why should there be a content type directive to say the same thing?