I have a web application that I have recently place behind a load balancer. There is a page that has the javascript:history.go(-1) method in a link. The previous page is a form that performs a submit. When I click on the link that performs the go method, going to the server directly, does not try to resubmit the form. But when I click on the same link through the load balancer the form does a resubmit. Does anyone have any ideas on how to perform this task through a load balancer so the link does not resubmit the page?
This behavior could be caused by not having "sticky sessions" enabled in the Load Balancer. It wouldn't know the resulting page load from the go is coming from the same user, so instead of simply displaying the page, it's re-serving it.
Do you know if it has "sticky sessions" enabled or if that's an option?
If possible, use the Post/Redirect/Get pattern for the "previous" page. In other words - process the POST request and instead of returning a result redirect to another page. It will be loaded using GET and the form won't be re-submitted upon navigating back to it.
Related
Basically what I want is this: https://dev.to/videos
You can select an item -> new page with item loads -> you click on backward button -> the old page is loaded from cache
I want that the same search page shown to user on navigation back, without calling the async fetch method again.
A solution seems to be SPA? But that is an enormous overhead.
I know how to do this with SPA. I need way without SPA.
iPhone, Android and Safari have a backforward-cache enabled by default, so no problem there. Static pages also don't have any problems.
I don't need any excact JavaScript code. I just want to know how do other websites solve this problem? Is SPA the only way? Are there any "frameworks" to solve this problem?
If server allows the page to be cached, your browser won't send a request again before the page expires.
https://stackoverflow.com/a/36554152/14263615
I'm searching for a lightweight way to change the URL by refreshing the site. Or detect when the URL is an error 404 and redirect it immediately back to the homepage.
I saw some ways with jQuery but I really just want to use something lightweight.
more info:
I'm building a onepager Portfolio which changes sites immediately without refreshing. but I want the to behave like a normal page, So I found a way to change the URL Path so when I click a link it also shows on which page I am in the URL.
The problem is when I refresh the page it wants to load the fake URL which is obviously not existing. So I need a way to change the URL when I refresh to a wrong URL Path.
I will be super thankful if someone has a solution for me because a dream would become true.
when you refresh, browser sends the URI to server to parse it, so there is no way to redirect it client side(ie. javascript)
you have to set up redirect on the server.
what backend are you using? are you using nginx?
You might be looking for this https://es.wikipedia.org/wiki/Single-page_application
Otherwise if you want to set it up a simple page all yourself I would just use CSS visibility in your logic while changing the URL.
On a real estate website I'm working on I have a Contact Us form on the Property Details page where the user can click the Contact Us button, which will load the form in a modal dialog, an iframe loading the contact us form, fill in some details and send it off.
Once the form has been processed server side I have to emit JavaScript code from the server that calls the dialog close method and then redirects the user to a thank you page (If I did a simple redirect on the server the iframe would get the thank you page which I don't want).
The problem is in Chrome where if you hit the Browser's back button the contact form is quietly resubmitted.
Note: IE and Firefox don't have this issue at all.
I found the following links useful, but not the answer to my problem:
https://productforums.google.com/forum/#!topic/chrome/J1KMARIIHW4
https://code.google.com/p/chromium/issues/detail?id=263508 (this one seems very close to the behaviour I'm seeing - but it seems like a bug that has continually resurfaced over the last couple of years)
Chrome executing all JS again on browser back button
We've tried various techniques to circumvent the issue in Chrome like hidden fields, insured cache is turned off, destroy the iframe before redirecting to the thank you page. Nothing it keeps resubmitting the form without even asking if you want to resubmit (not that it should be resubmitting at all)
Just come across this issue, what I'm thinking of doing is including some sort of one-time token (i.e. GUID) in the form, which if we re-detect on the server we can ignore the form post. Possibly use session state on the server to keep track - much like a Rails authenticity token
I have been thinking about this but can't figure out due to lack of familarity with how actually facebook is designed to work. If you can help and point me in right direction that would be helpful.
Problem: If you are at a group page and someone post a message you have to reload the page to see the new post. Which is annoying if it turns into chatting.
Possible solutions: that i've come up with..
extension detects new notification...somehow decide if it's about the page we are at, if yes then in background load the page get the new data and add the stuff to the page already opened. (don't know if it's even possible with the extension)
2nd idea is load after detection and confirmation just reload the page and retain all text that's been written and just scroll to that post again. I inspected the post structure it all looked randomly generated string...couldn't tell if any of the class or id were reliable to identify the textbox.
3rd idea is make new page bottom up that relies on some sort of sdk and updates pages as new post come in..(least favorable to me).
4th idea is forget about retaining the text that has been typed, if all inputs are empty and there is new notification reload the page...( i really wish reloading wasn't involved.
You can use the Javascript SDK and an AJAX post. When the server responds, if nothing extraordinary happened (no access token is expired, your facebook app is allowed), then you can handle whatever you want in the callback.
I thought that JavaScript didn't allow you to update the browser's URL (for bookmarking, etc) without doing a full page refresh. Facebook seems to accomplish this in their photos application, though. When I click "next" to see the next photo, the new photo loads and the URL updates, but the whole page doesn't refresh. Does anyone know how they accomplish this?
They don't update the URL per se, they only update the Hash (i.e # followed by instructions). The hash is never sent to the server, but can be used to go to anchor points in the DOM (built in browser functionality), or used as a hook for JavaScript. Upon page load with a hash variable set, they send an Ajax-request to fetch the corresponding photo. The initial page load will, however, load the picture indicated by the url before the #-character.