I am doing some basic HTML exercises on a Mac OS 10.6.6.
Say I am here:
rootfolder/index.html
and I want to go here:
rootfolder/subfolder/index.html
I understand I can use the relative path to make a link:
link to subfolder
^ this works for me in my browser.
And if I wanted to shorten the href, I could just do this:
link to subfolder
When I click the short version in my browser, the link takes me to the folder on my desktop (not to the page in my browser)
I'm wondering, do the files need to be in a web host environment for
the short version to work in a browser?
When /bob/ => /bob/index.html works, it is generally because the server has listed it as its directory index, e.g. with Apache...
DirectoryIndex index.html index.php
...meaning in the request of a folder, it will first look up to see if an index.html or index.php exists (in that order).
So if you are running it from the folders of your local filesytem (i.e. on the file: protocol), it has no server and does not know that a blank directory should request index.html.
The serving of index.html (or index.cgi or default.asp or whatever) when requesting a url that points to a directory is done by the server, not the browser. It is usually done as a result of configuration setting.
It's neither a property of HTML nor a property of urls.
If your browser doesn't serve index.html — and I don't know any that do — then you've answered your own question.
Mac OS comes with Apache (the most commonly-used open-source web server) pre-installed. You can set it up by going to System Preferences, choosing the "Sharing" preference pane, and then checking the box to turn on Personal Web Sharing.
Once you've turned on Personal Web Sharing, http://addressofyourcomputer/~yourusername/ will point to the Sites directory in your user's folder in Mac OS (i.e., /Users/yourusername/Sites/). With Apache running, if you go to http://addressofyourcomputer/~yourusername/subfolder/, it will in fact serve up /Users/yourusername/Sites/subfolder/index.html if there is an index.html file in that subfolder.
Without turning on Personal Web Sharing, though, there is no server running, and so your browser is really just directly accessing your computer's filesystem. As a result, when you ask for a folder, it literally returns you that folder, whereas Apache server knows the convention that /subfolder/ is really a request for /subfolder/index.html and will re-direct you accordingly.
The default page setting/redirection works only on web servers. The browser do not have intelligence(?) for such redirection. So the second option will not work.
Related
I have MediaWiki installed on a synology server. I would like to create a link on the wiki that would allow opening of files on the same server.
Here are the steps I did to achieve this:
Added $wgUrlProtocols[] = "file://"; in LocalSettings.php
A test file on the server: file://myServerName/path/to/file/test.txt. Putting this URL in my chrome browser directly opens the file.
Create a page in MediaWiki with a link to this file using [[file://myServerName/path/to/file/test.txt]]
When I click on the generated wiki page, nothing happens. However when I hover on top of the link, it shows the correct URL.
Can someone please point out what additional steps I need to do to get this working?
The file:// protocol points to the file on your computer. I'm not fully sure, but I think you cannot use it to retrieve file from a different machine (read my comment below about samba shares).
From quick research it looks like Chrome browser blocks requests with file:// protocol, But browsers like IE should allow you to open those files. It is done because of security reasons so the malicious site cannot open local files without your permission. You might bypass that by installing a special plugin in Chrome (look for Enable file links)
Instead of using file protocol, make those files available via Synology WebStation, and then create links that point to the file via webstation (not via path on the server). With that approach, links attached on your MediaWiki pages will work as those will be regular links.
If you don't use the WebStation, you might also try with ftp:// links (use the FTP service), or link to samba shares - that's where the file:// protocol might work, but again - I'm not sure and I cannot test it as I do not use windows.
I think that the safest/easiest/fastest way is to expose those files via WebStation.
Source: https://en.wikipedia.org/wiki/File_URI_scheme
The file URI scheme is a URI scheme defined in RFC 8089, typically used to retrieve files from within one's own computer.
I was learning about HTML domains and paths in my computer-science class. However, I have a question. What happens if you only specify a domain, such as apple.com instead of specifying a path? Does the page automatically give you the index file or something?
Thanks :)
That entirely depends on what the web server is configured to do. What you’re doing is you’re requesting a URL from a web server via HTTP. That does not inherently have anything to do with files. The web server can respond to the request in any way it wants.
But yes, most typically the average web server will look for a file named something like index.html in its webroot folder and return it.
yes, there is the default file that is returned if no path is provided
From Apache documentation
Typically, a document called index.html will be served when a directory is requested without a file name being specified. For example, if DocumentRoot is set to /var/www/html and a request is made for http://www.example.com/work/, the file /var/www/html/work/index.html will be served to the client.
From IIS documentation:
Default documents are enabled by default, and IIS 7 defines the following default document files in the ApplicationHost.config file as server-wide defaults: Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm.
(If you install ASP.NET on your Web server, the installation process will add the Default.aspx file to this list.)
Any ideas to why when I go to my site URL it's not pulling the index page? The index page is in the root directory. This was working before but for some reason it has stopped unexpectedly.
devoffpod.purplebottlemedia.com this should pull the site up but doesn't unless I specify the /index.html at the end.
Your default document settings are set to load index.php either before or instead index.html. You'll need to change that. If you are in a shared hosting environment, look at the community help and support section. If you are hosting this yourself in Windows, open IIS and then default document. IIS allows multiple default documents, so if you want index.html to load instead of index.php, make sure index.html is at the top of the list. (Or just before index.php)
I am not sure how to do it on a Linux based server or Apache, but I am sure there are plenty of online forms for changing the default document settings.
I'm having troubles serving a document which is in a higher level than my root folder.
<a href='../../home/folder/document.docx'>Proposal</a>
In the browser the above gets interpreted as:
http://localhost/home/folder/document.docx
I cannot see the browser going up in the folders and then the answer I get is:
Not Found
The requested URL /home/folder/document.docx was not found on this server.
I have tried in Firefox and Chrome, it happens the same. I am using Apache Web Server on a Linux machine.
Any help will be appreciated.
You can not redirect your visitors to a file outside of your document root (where you have your index.html).
People can't see files higher than where http://localhost/ ends up in.
A solution would be to put that .docx inside of your document root (where your index.html is in).
You can however let PHP serve the file using the readfile function.
But don't forget that www-data would need to have access to the file you're serving.
I have this structure for my project:
Root Directory
|-css folder
|-style.css
|
|-it folder
|-index.html
If I try to include css file with:
<link href="/css/style.css" rel="stylesheet" type="text/css"/>
from index.html, aptana preview and also internal server can not find style.css.
Why is this?
In my remote server it works perfectly and I do not want to use a relative path.
In terms of the "why", the problem you are having is related to how your development server is setup versus your production server.
Assuming a standard setup, your production server will receive requests for a domain (i.e., http://mysite.com) that is, for lack of a better word, mapped to a folder on your server (i.e, a request to http://mysite.com will be mapped to a folder, /var/www/mysite, on your server).
So, when you link to a style sheet with /css/style.css, your (production) sever immediately goes to the /var/www/mysite folder and starts looking for the css folder, file and so on. No problems with that, as you point out.
Your development machine, however, is serving up pages locally and has a different directory structure for mapping to files and folders.
When I open an HTML page in my Aptana project and hit the preview button, Studio loads http://127.0.0.1:8020/mysite/public/404.html (note how the first folder after the IP and port is mysite). To load the absolutely pathed CSS file, the local server is actually looking for http://127.0.0.1:8020/css/styles.css but it needs to get to http://127.0.0.1:8020/mysite/css/styles.css.
The initial "/" in your link (/css/styles.css) tells the server to go to the root directory of the server and start looking for the folder and files from that point ... but there is no css folder in the local server's root directory. It lives in /mysite/css/styles.css and that's why fskreuz suggests relative paths and using "../css/styles.css" instead.
Personally, I prefer absolute links (but that's just a personal preference and not in any way a challenge to or comment upon fskreuz's response). However, my local development setup is conducive to using them because I setup virtual hosts for the sites I work on. Using Apache, I setup a virtual host for each of my projects. With this, I can load something like http://dev.mysite.com in any browser on my computer and test my site/app in a way that makes it mirror my production setup.