This question already has answers here:
Why would a developer place a forward slash at the start of each relative path?
(4 answers)
Closed 9 years ago.
I noticed today just by chance that sometimes I write "/directory/file.extension" instead of "directory/file.extension" and that both seem to work sometimes. It seemed as though "directory/file.extension" worked every time among HTML, JavaScript, and PHP. In some cases, PHP did not like "/directory/file.extension" such as when using include.
In general is it better not to use the forward slash among HTML, JavaScript, and PHP? Does it matter for HTML and JavaScript?
I'm looking for an explanation as to why or why not more so than just a confirmation.
If a path doesn't begin with / it is a relative URL. This means that the actual pathname is determined based on the URL of the document that contains the URL. So if you have a page with URL /dir1/dir2/dir3/file.extension, and it contains a link to directory/file2.ext2, clicking on the link will go to /dir1/dir2/dir3/directory/file2.ext2. But if that same link were in a page with URL /dir1/file.extension it would go to /dir1/directory/file2.ext2.
Relative URLs are useful when you have a collection of pages that you want to move around as a unit, such as copying them from a development environment to production. As long as the relationships between all the files stay the same, the links between them will work.
If the path begins with /, it's called an absolute URL (strictly speaking, it should also contain the protocol, such as http:, and the server name //www.company.com). It will be interpreted from the server's document root, no matter where the link appears. Absolute URLs are useful for referencing files that are not part of the same collection. For instance, you might have a Javascript library that's used by pages at various levels in your document hierarchy.
Related
Recently I'm reading some webpages and I found there are a lot of usages like:
href="/./foo/bar.php"
Isn't this the same as href="/foo/bar.php"? Or is this there something I don't know about the differences between the two ways?
The relative URL /./foo/bar.php is not the same as the relative URL /foo/bar.php. The former has /. at the beginning.
They have the same effect, though. When URLs are processed, relative URLs are resolved to absolute URLs, and in this process, if a relative URL starts with /./, it is replaced by /. Reference: STD 66, clause Remove Dot Segments. (Such a reference is turn resolved as relative to the server root, basically something like http://www.example.com/foo/bar.php.)
So these two relative URLs always resolve to the same absolute URL. There is in general no reason to use the longer URL, which looks more complicated and confusing.
Note that this has absolutely nothing to do with folders or files. It is simply string manipulation, based on the URL standard. Whether URLs get mapped to folders and files is at the discretion of a server and in principle invisible to the world outside it.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
mod rewrite and query strings
The only way I know to pass parameters in the URL is using the GET method in PHP. But I saw many websites using what seems to be parameters directly in the URL, like this:
http://.../page/2/
In this case, is "page" really a parameter? If so, how is it handled in the code?
Or is this a regular URL of a directory "2" located in a directory "page"? Would it mean that whenever a new post is created, the website creates all the pages and the corresponding directories?
Thanks
This is called url rewriting. Basically this means that you use an apache module to rewrite incoming urls to new urls which are then handled by apache
In your example http://www.test.com/page/2/ is probably rewritten to something like http://www.test.com/?page=2.
If you search the internet for Apache URL rewrite you will get enough results explaining how you can do this.
These are all conventions. GET parameters are not specific to PHP, this is how all browsers encode form data. Java-based webapps use semicolon-separated parameters for example.
You can write a simple layer to convert ?alpha=1&beta=2 to /alpha/1/beta/2 but iw tould be just a cheap gimmick (except in a very few legitimate cases like with Squid caches).
What today's websites do is to use a single entry point pattern. Usually with apache's mod_rewrite, all requests are handled by the index.php and there is a routing facility to choose the adequate handler PHP file for a specific URL scheme. These schemes can be easily defined by Regular Expressions.
So all in all you decide how your URLs are going to look like. It is not an easy task and there are many SEO snake oil salesmen out there who will make you do all kinds of crazy stuff. What a good URL does is to identify a content (document) inside your service and you must use that single URL throughout your service to address it.
And don't forget: cool URLs don't change. You will abandon your current code base in 2 years and rebuild your site from the ground up. Design your URL scheme in a way that makes sense from a logical point of view and not something dependent on your webapp design.
The example you gave is still a GET request.
What you are looking for is URL rewriting.
Hello I am trying to make a little spider.
While I was building it I came across a problem where I need to check if a link is a root domain link or a subdomain link.
For example:
http://www.domain.com or
http://domain.com
http://domain.com/index.php
http://domain.com/default.php
http://domain.com/index.html
http://domain.com/default.html
.
.
etc
are all the same.
So I need a function actually that takes the string url as an input and checks if it's the root or homepage whatever you like to call it of a site.
As noted in comments, this is really a basic aspect of coding the spider. If you intend to code a general purpose spider, you'll need to add means to resolve URLs and detect if they point to the same content and in what way (through a redirect or simply through duplicate content), as well as what kind of content they point to.
You need at least to handle:
relative paths
GET-variables that are in one way or another significant to the web page, but does not render differences in the content.
Malformed URLs.
JavaScript related information in the href attribute.
Links to non-HTML material -- direct download links to PDFs, images etc. (detect it on extension isn't always enough, what with PHP scripts delivering images).
These are just some of the aspects but it all comes down to the point that the kind of detection your after have to be a fundamental part of the spider if you intend to use it in any kind of generic manner.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What's the shebang (#!) in Facebook and new Twitter URLs for?
It usually comes straight after the domain name.
I see it all the time, like in Twitter and Facebook urls.
Is it some special sort of routing?
# is the fragment separator. Everything before it is handled by the server, and everything after it is handled by the client, usually in JavaScript (although it will advance the page to an anchor with the same name as the fragment).
after # is the hash of the location; the ! the follows is used by search engines to help index ajax content. After that can be anything, but is usually rendered to look as a path (hence the /). If you want to know more, read this.
In my php script I created a constant variable that defines the base url to be put in my hyperlinks, but do I really need this?
Here is an example of what I mean.
I have this:
// base url is only defined once and reused throughout
define("__BASE_URL","http://localhost/test1/");
print '<a href="'.__BASE_URL.'index.php?var1=open/>Open</a>';
(I have a lot of these spread throughout my script.)
I tried this and it works:
print '<a href="index.php?var1=open/>Open</a>';
So which way is the proper way on doing this? I noticed the second way even works on loading images, css, and javascript files.
It really comes down to how you're structuring your site. Relative URLs are great (by doing href="index.php" you're reallying saying href="./index.php"), but they can start to become messy when you begin spreading pages over multiple directories.
Personally I like to base all of my relative URLs off of the root directory, meaning that all of my URLs start with a slash ('/'). That way it doesn't matter if my script is in / or /admin, as I will always have a constant reference point - the document root - as opposed to some relative directory in the structure.
Your first example, storing document paths in variables, really starts to come in handy when you begin developing larger systems where you want the paths to be configurable. For example, maybe you want your system admins to be able to define where images are pulled from, or where the cached downloads are.
So really consider your use cases and size of your system.
Also keep in mind that if you ever move the script to another server that your URLs and directory structures may change, which could cause havoc (ex., you might have your script moved to a different subdomain, into the document root, etc.). A lot of people will drop in Apache's mod_rewrite in this case.
It depends. Without the __BASE_URL, your link will be relative to the current document. In your case, that means index.php must be in the same directory as the file that has the index.php link on it.
If you have the __BASE_URL, then the link will work no matter where its containing file is located (i.e. doesn't have to be in same directory as index.php).
Another option is to use a starting slash only. Then your link will be relative to your domain root:
print '<a href="/index.php?var1=open/>Open</a>';
In other words, the above link would point to http://localhost/index.php.
It sounds like your question is regarding absolute vs relative URLs. Are you going for portability? It's generally best to use relative URLs, especially if you plan to work in a test environment and then later transfer files to production.