As the title suggest, I misunderstood 301 page redirect in one of my web applications which led to, that's right, a Bug!
Let's first try to understand why we need a page redirect and how should we use it. I will try my best to explain this using some scenarios below.
Suppose you have a website whose url is https://sellon.india.com. This website has all the things for SEO (Search Engine Optimization). Now your team has developed a new and better web application which can handle more complex things than this one. This web application is live with url https://seller.india.com. Business requires your user to be redirected to the new website whenever someone tries to open the old one.
Upon login into your new web application, user should be redirected to his/her home page based upon the roles/permission he/she has.
HTTP codes for redirection are 30X (where X is from 0 to 7). For the sake of simplicity I will take only 2 status code into account, i.e. 301 and 302.
As per w3.org1 this is what they mean -
301 - The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs
302 - The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests.
So which redirect code should you use? It's pretty much clear that for scenario 1 it will be a 301 and 302 for the other one, but what if you used 301 for Scenario 2?
Let's try to understand what can happen if you used 301 for Scenario 2 as it happened with us -
User A has an Order role and whenever he/she logins they are taken to /order page , i.e.
Requirement changed a little bit, now the user has to accept an agreement and only after acceptance he/she needs to be redirected to /order, i.e.
So we implemented this feature and asked the user to login. Ideally the above flow should happen, but it didn't, and the user went to /order page without accepting the agreement after login. The agreement page never showed up. However when using an incognito tab2 we saw this agreement page coming. Since incognito tab in chrome uses fresh cache store, it was clear that the issue was related to caching.
The culprit that was helping in caching this was the status code we were using for /order. It was a 301 redirect.
301 status code tells the client that the url has been permanently moved to a new location. So when the users were logging into the web application the response got cached to /order. Sending an new HTML response or a new url redirection was giving us
301 Moved Permanently (from browser cache) and the user was going to /order page.
We had no control over this and the users had to manually clear the cache in order to accept agreement. This led to many emails from customer support team to us.
Not using correct status codes can cause bad user experience which can lead to business loss too. Make sure that you use codes for what they have been built for.
Original Post Syed Haani Blog
If you want to add more comments to the article or you see any thing incorrect please write a comment below and we will surely get back to you.
Incorrect table definition there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause