One of the most critical things to understand about HTTP is that URL paths are
not the same thing as filesystem paths.
It's very easy to confuse them for 2 reasons:
1) A URL path has the same basic syntax as a Unix-style filesystem path (directory/directory/directory/file)
2) The default action for most webapp servers (including all J2EE/JEE ones) when presented with a URL path that hasn't been explicitly mapped (by a web.xml servlet-mapping element) is to use the URL path as a model for a corresponding location in the WAR.
Technically, a WAR is a JAR (ZIP) file, and like any other ZIP file, the "directories" and "files" within a WAR are not actually filesystem paths either, since the WAR is a single file*, but I hope you get the idea.
In actuality, an HTTP/HTTPS URL breaks down as follows for a URL of something like
https://coderanch.com/mooseImages/moosefly.gif:
The https is the
protocol that the client will be using.
The www.coderanch.com is the server domain name of the coderanch server.
An optional port number (for example ":8080" would follow the domain name, but in its absence, a default port is used. For the https protocol, that is port 443.
Following the server domain name is the webapp context path that determines which of possibly several webapps that the server houses should receive the URL request. The sample URL has no context path - or to be more precise, the context path is the root context ("/"). The context path is defined when the webapp is deployed.
Everything that remains up to the query or anchor part of the URL (the "?" or "#" part) is the context-relative path of the resource you want to get back. So in our case, that's "/mooseImages/moosefly.gif".
To resolve this path the webapp server will first check web.xml to see if there's a resource (servlet) mapping. Nope. So we fall back to the default option. If the WAR is a WAR file, it will look inside the WAR file for the item named "mooseimages/moosefly.gif". If the WAR has been unzipped ("exploded"), however, then it actually exists as a directory somewhere that the webapp server knows about, and the webapp server will look at the mooseimgages directory within that WAR directory for the file named "moosefly.gif".
Note that resource paths are
always relative to the root of the WAR, never to the host or client filesystem. Properly speaking a resource path begins with a "/", so internally the resource path is "/mooseImages/moosefly.gif".
---
* Just to make things more confusing, many OS's these days allow you do look into ZIP archive files as though they were directories, but their true identity remains as a single file.