This question already has answers here:
.htaccess Rewrite to Force Trailing Slash at the end
(10 answers)
Closed 8 years ago.
I recently went to a webpage and noticed their directory page was customized.
putlocker.is/featured/
NOT
putlocker.is/featured
How would I costumize this on an Apache sever?
The URL you provide almost certainly isn't an Apache directory index (although there are some directives which can customise those, such as IndexStyleSheet). To achieve a custom page when a URL with a / on the end is requested then, given a vanilla Apache configuration:
Put an HTML document in that directory with a filename that is in the list specified by the DirectoryIndex directive. Usually this will include index.html.
You can also use a file that will generate HTML programmatically (such as PHP on a system with PHP installed) or divert the request (e.g. using ScriptAlias or mod_rewrite) to another program (which might use the front controller pattern).
Here is an example to use Catalyst for this purpose, you then define your URLs using Catalyst actions.
Related
This question already has answers here:
How can one get github pages to serve dot files like RFC5785's /.well-known/?
(1 answer)
Does pages.github.com support directory names with a preceeding . (dot)?
(2 answers)
Closed 11 months ago.
I had to add a .fol-der/file.txt file to my github pages repo for verification on a platform.
Problem is, I get a 404 error when I enter username.github.io/.fol-der/file.txt in the search bar.
I am not using a site builder like Jekyll, just html files of my own.
Any idea why this could be happening? Thank you.
I have found a fix.
https://github.community/t/also-serving-hidden-folders-after-publishing-to-github-pages-using-github-actions/18120
Just add a file .nojekyll in the root of your site’s publishing source.
I would have commented, but I don't have enough reputation points.
GitHub pages will not serve files or folders starting with a .. You will need to rename your folder so that it doesn't start with this character, or use a different hosting service.
This question already has answers here:
What does "./" (dot slash) refer to in terms of an HTML file path location?
(12 answers)
Closed 1 year ago.
I am trying to include an image that is in a local folder. When I try to load it standalone(not served from a server) it breaks. When I load it from a server it has no problem. If both point to the same location what is the deal?
ex:
<img src="/img/example.png">
vs
<img src="./img/example.png">
You would use ./ when you want the path to start from the current path. This is often called a "relative path".
You would use / when you want the path to start from the root path. This is often called an "absolute path".
Note that in this case "path" is the URL components from the site root to the resource name, it has nothing to do with file system paths.
When I try to load it standalone(not served from a server) it breaks. When I load it from a server it has no problem.
I don't know what you mean by "not served from a server", but both of the src values you demonstrate are relative URLs. If you mean that you're trying to open the page from the file system and not from a web server then note that ./ has pretty much the same meaning in file systems, but / does not. Depending on the file system, it may mean the root of the entire file system or it may mean nothing at all and just be an error.
If both point to the same location what is the deal?
If one is failing and the other is not then they both do not point to the same location. You can open your browser's debugging tools and observe the requests made to load the image resources. Those requests would include the full URL (or file system path?) being requested by the browser, so you can see how your src values translate into actual requests.
As an aside, if you're trying to open the page from the file system then the short answer is... don't do that. It "works" for simple functionality, but a file system is not a web server. For any reasonable web development it's best to serve the content from a web server. (Which can of course be on your workstation for local development.)
This question already has answers here:
What's the actual meaning of 'two requests to the server' in this context?
(2 answers)
Closed 6 years ago.
The w3schools documentation says:
Without a trailing slash on subfolder addresses, you might generate two requests to the server. Many servers will automatically add a trailing slash to the address, and then create a new request.
It is not clear what exactly this means. What difference does it make to add a trailing slash in the href urls, is there a best practice regarding adding a trailing slash.
These are two different URLs:
http://example.com/foo
http://example.com/foo/
Often, but not always, requesting the first URL will trigger the server to reply with a 301 Permanent Redirect to the second URL. The browser will then have to make a second request to the second URL.
This is most commonly the case when the URL is mapped on to a directory on the server's file system and the index.html (or other directory index) is being loaded.
Servers where the content is being dynamically generated (e.g. with an MVC framework like Perl's Catalyst) are less likely to do this. In that case you often have to be even more careful with where you link to because relative URLs will resolve differently from the two URLs.
Fundamentally, http://example.com/foo and http://example.com/foo/ are two entirely different URLs. Ultimately what's important is how the server serving those URLs will respond when queried for those URLs. And it's entirely up to the server what to do. .../foo may return a file while .../foo/ may return a directory listing. Or both may return a directory listing. Or a file. Or the same file. Or a random new response each and every time.
What W3S is pointing out is that many servers are by default configured to return a redirect response to the canonical version ending in a slash. Meaning, if you're requesting .../foo from that server, it will redirect you to .../foo/, which then causes your client to do a second request to .../foo/. Why or how or when a server may issue this redirect is entirely up to each server, and whether it's really such a popular practice is questionable (as is everything by W3S).
The important thing is that you point your URLs where you mean to point them. Is .../foo the correct URL because it's a file? Or is .../foo/ the correct URL because it's the root of a (virtual) directory? You decide, you make sure your server behaves appropriately.
This question already has answers here:
Make index.html default, but allow index.php to be visited if typed in
(6 answers)
Closed 8 years ago.
Trying to upload a new site and the server isn't configured to resolve "html" rather than "htm" so I get the following message:
Directory Listing Denied
This Virtual Directory does not allow contents to be listed.
How can I reconfigure the server as opposed to renaming all the site files?
seems like an .htaccess file might be the answer but I can't find and/or remember what the syntax is that you put into it.
Easy way to do it: add the type to your root .htaccess file.
AddType text/html html
So: adds the MIME type text/html to files with extension html.
Hope this helps.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
.htm vs .html
What is the difference between .html and .htm file extension in a Basic Web Page?
None. I believe .htm to exist only due to the MS DOS limitation of 3 characters for file extension, which then propagated as a bad habit to early windows versions and programs.
There is none. HTM is the shorted version invented by microsoft for their old 8+3 file format, where each file could have only 8 characters in the filename and three in the extension.
notihing , you can find your perfect answer here htm/html
Whether a URL refers to an HTML page or not depends on the server's content-type not on its file extension. For instance htpp://www.google.com/ returns HTML even though no .htm or .html can be seen. You could even configure your web server to make this URL: http://my.server.com/foo.jpg return HTML instead of a JPEG image. As far as URLs are concerned file extensions do not have any meaning.
Basically, None.
.htm used to be normal when the length of the extension was important (in the days of 8.3 letter filenames) but that has not been an issue for a long time and .html is more common today since it is more descriptive.
So far as the web is concerned, you can use any extension you like or none at all (so long as the server is configured to send the right mime-type) - the extension is only an issue on your local computer.