I've run into a situation where I would like to be sure about how do browsers handle URIs that include a fragment identifier, such as Products#A. Imagine my website has two pages: Products and FAQs. Then, inside each I want to use # to navigate to specific HTML elements. So:
What is the difference between href="Products#A" and href="#A" if I'm already in page Products?
And if I'm in page FAQs?
Does placing an URL like in href="Products#A" always triggers a server call or does the browser know that it is already on page Products and it does not make a server call?
What is I add a / (like href="/products#A")? Does this force a server call?
Is this standard for all browsers?
I've run a few tests but I'm missing some theory here.
If the link, fragment excepted, resolves to the same URL as the current page, then it will navigate around the current page.
If it resolves to a different page, then it will load a new page.
It doesn't matter how the relative (or absolute) URL is actually expressed, only what it resolves to.
To answer your questions, I am doing these with my own experience.
What is the difference between href="Products#A" and href="#A" if I'm already in page Products?
Nothing. Just for safety, and if you are in a different page, and the content is rendered using the same partial (or the same source), this might help.
And if I'm in page FAQs?
It navigates normally to Products and finds the element with id="A" and scrolls to there.
Does placing an URL like in href="Products#A" always triggers a server call or does the browser know that it is already on page Products and it does not make a server call?
That's a client call, no server calls are made for URL fragments.
Is this standard for all browsers?
I believe so.
Related
This might just be because I'm not entirely sure how to word it properly, but here's an overview of the problem.
I have a site where it pulls the main content using ajax, and by using pushState, I change the url. Say from "site.com/" to "site.com/area". But reloading this page (or entering it in the url) causes it to completely fail (because there's no such thing as site.com/area).
Is there a way to load the page from that link?
Note, that this isn't about the history / back and forward buttons. I simply want it to load a page from that kind of link.
The page must exist in one way or another. Depending on what server you're running it on you can redirect all requests to your first page if you want to solve it like that. Then you don't have to create a new page for all "routes", but can build it into your first page/application.
But the page must exist in one way or another.
Okay so there are solutions for this as in Modify the URL without reloading the page but I have one question regarding this.
So here is what I plan to do (let's assume my web address is example.com)
1. using pushState I plan to change the browser address to example.com/myprofile/myalbum. So to be clear, this new url may or may not exists but the browser address is changed regardless. In our case this url doesn't actually exist but we are using the address to mark a changed state of the webpage.
2. use ajax to load data regarding "myprofile > myalbum" to the same page.
But now here's the issue I have been thinking about. What if a user loads example.com/myprofile/myalbum directly on a, let's say, new tab. This page clearly throws a not found error because it doesn't exist.
So how do I load ajax corresponding to this fake url? For example http://www.usatoday.com/news/ seems to do this well (unless that's an iframe, which wouldn't be so nice).
You can add rewrite rules to your webserver, converting either specific URL's or some matching a pattern to something that your scripts can use to show the right page. You can have it rewrite the URL only internally, so the user still see the original URL in the browser. Such as:
RewriteRule /myprofile/(\w*) /index.php?path=/myprofile/$1
Different webservers will probably have different syntax, but they will be similar.
So I have my site at http://example.com/foo/ (under a directory, the main domain is for something else).
Using .htaccess, I've set up my pages so the URLs look like http://example.com/foo/about/, http://example.com/foo/polls/, http://example.com/foo/registration/, etc. This works great and the site loads fine and can be traversed without any Javascript issues.
Now, I'd like to add some AJAX functionality to the navigation. If I'm on http://example.com/foo/ and I click the navigation for "About", it changes the URL to http://example.com/foo/#about and dynamically loads the about page in one section of the site. I also have this working.
I have two problems which involve handling switching between AJAX and non-AJAX URLs.
If I'm on http://example.com/foo/about/ and I click on polls, it would look like http://example.com/foo/about/#polls which doesn't look very pretty. Ideally, I'd want every AJAX URL to be formatted with just the main directory and a hash, like http://example.com/foo/#about.
Should I handle it by forcing an actual (non-AJAX) redirect to the index page with a hash symbol then load it from there?
The other problem is the reverse. If I send http://example.com/foo/#about to someone who has Javascript disabled, or maybe if someone links to it and a bot crawls that link, is there any way to handle that to redirect to the correct non-AJAX page or is this just an unfortunate fact of life I'll have to deal with?
If you need non-javascript support, I'd change all your urls directly to the pages. Like http://example.com/foo/#about to http://example.com/foo/about/
Then, the javascript can intercept it, call event.preventDefault(), and 'redirect' it to #about, which will follow your ajax functionality.
If the client doesn't have javascript, it will go to http://example.com/foo/about/ as normal.
As for being on http://example.com/foo/about/, a javascript client should never get here as they will always be redirected to hashtags.
1) if you redirect to the main page and then use ajax to load the about page that would just not make much sense. what you should do is make everything work through ajax : there should never be a http://example.com/foo/about/ in the first place only http://example.com/foo/#about then you just update the hash and the content when you click on polls.
2) there is no way to avoid, sorry.
Facebook examples show two different methods for redirecting a user's browser.
Script:
echo("<script> top.location.href='" . $next_url . "'</script>");
Header:
header("Location: $next_url");
I have noticed some differences in behavior between them, but do not have enough knowledge of HTTP theory to understand these differences and know which one to use for different cases.
I have a basic sense that the header approach is more of a "hard" call to another page with a clean refresh, and the script approach is closer to a "soft" call (like Ajax) that may work on top of and within the existing page that makes the call.
Can someone give (or point me to) a good explanation of the differences between them, with examples of suitable use cases for each approach? Thanks!
This probably has a duplicate somewhere, but I can't find it right now so...
A header() redirect takes place before any page data is output. As the name says, the browser makes a request for a page, and the page's response headers contain the instruction to go to a different address. The browser will usually immediately do so.
A JavaScript redirect takes place inside an already loaded page.
If at all possible, you want to use a header redirect because it makes the browser go to the new resource straight away, without having to render the intermittent page first. Also, it works for clients that have no JavaScript enabled.
I've coded an HTML page using jQuery for loading content. Now if I want to link directly to a submenu, is this possible to do with JavaScript?
So for example if someone goes to www.mydomain.com/submenu1/
then some JavaScript code will execute and load the needed contents?
Thanks a lot :)
Is it possible to realize that with htaccess?
You will more likely want to have a URL structure that only needs a page to load from the server once, then the server is only queried by JavaScript XMLHttpRequests. Loading content based on a "hard" URL would be pointless, since you're doing a server request anyways and might as well return the content in the response.
For keeping addresses unique while still keeping the "hard" URL the same (preventing multiple server requests), you can use the hash/anchor part of the URL. This means your address might look something like this: http://www.example.com/#/submenu1/
The #/submenu1/ part stays on the client, so only / on www.example.com is requested. Then it's up to your JavaScript to load the content relevant to /submenu1/. See a page of mine for an example of this: http://blixt.org/js#project/hash?view=code
Also have a look at this question: Keeping history of hash/anchor changes in JavaScript