I work as the Helpdesk Tech and I also do updates to our hosted Intranet website where I typically provide links to various documents and other resources.
I had a link that used to work (up until about 2-3 weeks ago) which would point our users to view a directory (entire folder full of documents) located on our web server. I did this to save time rather then creating links to each individual document.
This way as I create more documentation, I can simply upload it into this folder and users could view it instantly.
Approximately 2-3 weeks ago the link stopped working as well as a few other links which I was using which pointed to other directories/folders on the Web server.
The hyperlink method that I used was "..\<directory path>" which would call the page to navigate up one level in the site hierarchy, then open the directory which I specified and display all of the contents.
*** I must note that this never worked in Firefox, but would work in IE 8 and 9 (until recently).
Now when I click the link, it displays a 404 error and doesn't open the directory page view like it used to. I have verified that the web address that the page attempts to load is correct by entering a specific file name after the forward-slash (and the individual file loads properly).
Notice that on your "404" page that the filename components use "/" instead of "\"? The backslash is a Windows/DOS filename separator. The "real" a/k/a forward slash is the separator for URLs.
A web server is not a file server.
While this difference is most blatant at the application program level, it's also true when attempting to fetch resources. The only reason that you can fetch files or list filesystem directories at all via a web browser is that there's a default servlet that, given a URL that it cannot find a servlet or JSP that matches, converts the URL to a relative resource pathname and lists the resource using a directory listing or - if it's a file and not a directory - returns the contents of the file.
I'm using the term "file" as a shorthand here, since officially, a WAR is always a ZIP, and the "files" and "directories" inside a ZIP file are actually just expanded data from inside that file and not truly files in the sense that filesystem I/O calls can open and read or write them (Note: don't attempt to write to WAR resources, regardless!). Which is why when I'm being pedantic, I call them "resources" rather than "files".
In the real world a lot of times, the WAR file has been exploded into actual directories and files, but that's mostly incidental here.
When presenting a directory as part of a webapp, there are a few caveats. As I mentioned, it's not really safe to write files to a WAR directory. Even when the WAR is exploded, those files can get nuked if the webapp is updated. Excuse me. Will get nuked. So the actual server filesystem location for a "documents" directory should be a physical directory located external to both the webapp and the appserver. More on this in a second.
There is another consideration as well. Since a webapp is not literally a directory of files, any attempt to peek uphill outside of the webapp has 2 issues. First, the webapp context root is (allegedly) the end of the line as far as the URL is concerned, so you shouldn't be able to do it to begin with. Secondly, any webapp server that does permit such behavior has a major security bug and sooner or later, hopefully that bug will be fixed. Otherwise, you've effectively given people free access to the entire server filesystem, and that's the stuff security nightmares are made of.
Back to the documents directory, though, assuming no "uphill" URLs. How do you provide a documents directory within a webapp when you aren't supposed to put updatable resources within a WAR?
There are 3 ways.
1. Make the directory be a filesystem link (softlink or hardlink) to the external directory. You'd have to ensure that the WAR was exploded and manually create this link in the exploded WAR. You also must check your server configuration settings, since for security reasons, referencing WAR resources via filesystem links (which are NOT the same as hyperlinks!) may be disabled.
2. Provide a servlet that accepts the resource URL, parses it into the appropriate external filesystem path and then either lists (directories) or retrieves (files) the requested resources. This is the more portable, less troublesome solution, but be very sure that when you parse incoming URL paths that they don't allow "walking uphill" out of the resource directory or you will have opened up a serious security hole yourself.
3. If the documents directory is itself visible as a filesystem share, then most browsers - including Firefox can fetch the resource directly, without going through a webapp. For example: "file:////myserver/docdir/policies/conduct.docx" would be a URL that accesses the "conduct" document using its UNC filesystem pathname in URL form. Because URLs can refer outside the scope of the immediate webapp, such URLs could even be published the same way that other hyperlinks are. However, there is one limitation: if the client doesn't have filesystem access rights to that file via LAN shares, the link won't be usable.
Customer surveys are for companies who didn't pay proper attention to begin with.