I like to think of it as re-issuing my last request. If you performed a simple GET, it would probably return the same thing it did last time (minus dynamic content). If you had done a POST, you're going to resubmit the form (after confirmation) to the server.
A history of pages viewed is kept in a stack-like form. When you "pop" the top three pages (A, B, C, for instance) and then go to a different page D, you cannot get to B again by hitting forward.
I think the easiest way to explain this is in pseudocode:
class Page:
String url, ...
Page previous, next # implements a doubly-linked list
class History:
Page current # current page
void back():
if current.previous == null:
return
current = current.previous
refresh()
void forward():
if current.next == null:
return
current = current.next
refresh()
void loadPage(Page newPage):
newPage.previous = current
current.next = newPage # remove all the future pages
current = current.next
display(current)
Your web browser keeps a stack (or list, if you will) of the web pages that you have visited in that window. Let's say your home page is search.example and from there you visit a few other websites: video.example, portal.example, and news.example. Upon visiting the last one, the list looks like this:
At this point you can press Back again to take you to video.example, or you can press Forward to put you at news.example again. Let's say you press Back a second time:
If you now go to, say, example.com, the list changes to look like this:
search.example -> video.example -> example.com
^
|
current page
Note that both portal.example and news.example are gone from the list. This is because you took a new route. The browser only maintains a list the pages you visited to get to where you are now, not a history of every page you've ever been to. The browser also doesn't know anything about the structure of the site you're visiting, which can lead to some surprising behavior.
You're on a shopping site (shop.example, as a short example) that has categories and subcategories of products to browse through. The site designer has thoughtfully provided breadcrumbs near the top of the window to allow you to navigate through the categories. You start at the top page of the site, click on Hardware, then Memory. The list now looks like this:
You want to go back to the Hardware category, so you use the breadcrumbs to go up to the parent category instead of using the Back button. Now the browser list looks like this:
According to the site structure, you went backward (up a level), but to the browser you went forward because you clicked on a link. Any time you click on a link or type in a URL in the address bar, you are going forward as far as the browser is concerned, whether or not that link takes you to a page that you've already been to.
Finally, you want to return to the main site page (shop.example). You could use the breadcrumbs, but this time you click the Back button -- it seems obvious that it should take you up one level, right? But where does it take you?
It's initially confusing to many users (myself included, when I happen to do exactly this) that it takes you "down" a level, back to the Memory category. Looking at the list of pages, it's easy to see why:
To go back to the main page using only the Back button would require two more presses, taking you "back" to the Hardware category and finally to the main page. It seems so obvious to us programmers what's going on, but it surprises the heck out of regular users all the time because they don't realize that the browser doesn't know anything about the hierarchical structure of whatever website they happen to be on.
Would it be great if browsers would let site designers program the Back button to do the obvious thing (take you up a level) rather than whatever it does now?
A commenter asked whether the browser reloads the page or simply displays it out of its local cache.
The answer is it depends. Site designers can specify whether the browser should cache the page or not. For pages that are set as non-cached, the browser reloads the page from the server when you press Back, as though it was the first time you are visiting it. For cached pages, the browser displays it out of the cache, which is much faster.
As a devoloper, you should make sure that your webapp works no matter how the browser handles the Back button :-) Does it resend the request? Is the new request identical to the old one, or does it differ in any way? Will browser ask user to confirm re-POST? What elements of the page will be re-requested and what loaded from cache? Will browser respect my cache-control headers?
Answers to these question depend on make, version of a browser and user settings. Design you software so that all this doesn’t matter that much.
Sorry for not very direct answer, but there are some straight answers here already.
a browser always stored the pages for its remembering and when we press the back button
it doesn't send the request to server for the previous page instead it just see its cache
where it stored the pages and it follow the LIFO rule that is why it give us that page first
on pressing the back button which we opened in the last
There is something I want to add as a complement.
When you hit the back button in your browser, or(alt+left) in chrome, the browser actually just loads the cached HTML file in the history.
it doesn't send another GET request to the server,
so when you go back in some ecommerce website and pass the password again it will throw exception to you.
it's true some web pages do not allow you to cache itself but that's rare, and in that case or the cache has expired, the browser will send the GET request instead of using the HTML from the cache.