0

This seems to be a serious issues with Bit.ly URL shortening service. Actually, I have created a bit.ly URL1 like "http://bit.ly/xyzabcd" to my URL2 "www.myserver.com/myjson.txt".

Case 1: Hitting the bitly URL1 I am getting the response whatever it is in myjson.txt. This is expected.

Case 2: If I update the URL2's json content and then hit back the bitly URL1 the browser is caching the response. This is BAD case.

Case 3: If I manually hit the URL2 then I get the old response, but after appending URL with some random no, it is getting new response as expected. This is manual.

My Real Use Case: I am using this bit.ly URL in my Chrome Extension App and it is failing to work on updated response because inside the bit.ly URL1 is caching old response itself.

Here the issue is we can't modify bit.ly URL1 and we can't let bit.ly to modify(append any randon no) my URL2 response.

I appreciate your help and advice to resolve this issue. I was assuming the bit.ly will always fetch the latest response, but it is FAILING in this Case 2!!

Veeresh Devireddy
  • 1,057
  • 12
  • 24
  • 1
    This is because either your site is not returning that the data has been modified, I don't believe its `bit.ly` fault, rather your server's inability to say, data has been modified – Noam Rathaus Dec 31 '13 at 16:03
  • The Case 3 is describing that issue, if I append any random number query parameter to URL2 then I am getting the updated response, means no problem with my service providing the latest/updated data. But the bit.ly is failing to get the latest response, implicitly the browser itself caching the response, and bit.ly should have a way/solution to get the latest response. – Veeresh Devireddy Jan 02 '14 at 06:58

2 Answers2

2

nrathaus is correct. Bitly doesn't control the data sent from your server. We send a 301 redirect, which your browser should cache, but there is no content in that response other than the location of the long URL.

You should make sure that "www.myzerver.com/myjson.txt" is sending the appropriate headers to tell your browser to never cache it. See this StackOverflow answer for details on which headers to send.

James Socol
  • 1,795
  • 10
  • 11
  • I agree with you, but in this case the http resource(myjson.txt) is a plain json/text/file and I believe we cannot add any http headers to prevent caching at client side. Please let me know if you find any solution around this. – Veeresh Devireddy Jan 07 '14 at 03:28
  • In that particular folder I have even tried to create .htaccess file and set http header fields to prevent cache with below configuration, but still in the response headers I found caching parameters. Please check below: ---.htaccess---- ExpiresActive On ExpiresDefault A1 Header append Cache-Control must-revalidate Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate" Header set Pragma "no-cache" ` – Veeresh Devireddy Jan 07 '14 at 03:48
  • I couldn't paste it here due to this bad formatting rules, instead share it here - [link](http://justpaste.it/e0or) – Veeresh Devireddy Jan 07 '14 at 04:09
1

This is the case of some other url-shorteners when you have the ability to change the destination url with the same short url it always redirects to the old destination url. That's because of the browser cache of the response 301 redirect to old destination. When you add some random argument to the shortened url, it will return the correct destination url. It is a problem of the browser caching the redirect. If you need to confirm, insert the shortened url in a private session (incognito windows) and it will act correctly!

https://bugs.chromium.org/p/chromium/issues/detail?id=633023&can=1&q=clear%20301%20redirects&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

ouflak
  • 2,458
  • 10
  • 44
  • 49
Luis J. Polanco
  • 11
  • 1