I've noticed that if a short url is pointing to an image, the browser will cache that image and not update if the image changes (FF 5 does this for sure).

I added
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Cache-Control: no-cache");
header("Pragma: no-cache");

To shurly_goto to help fix this issue.

Is there anything wrong with this or should this be added to shURLy?

Comments

alexweber’s picture

alexweber commented

As far as I can tell this is a browser-related issue and has nothing to do with Shurly! :)

Sure, adding those headers might fix it in this case, but overall adding no-cache headers to every shurly request doesn't really seem like a good idea.

that0n3guy’s picture

that0n3guy commented

I agree with that for sure.

Maybe we need a simple extension check before the url is added to the database. If its a jpg, png, etc... then it adds a "true" flag in the database. Then when the url loads in shurly_goto, it also see's the flag and it adds the headers.

Possibly a setting in admin that says "check for direct image urls and not cache them?" so this can be turned on or off.

alexweber’s picture

alexweber commented

I'm going to have to say that whereas your idea is decent, it's still not Shurly's problem. It's a browser/server issue!

A given short url can point to any path or file/image. All Shurly does it simple look up the short url and redirect the user.

The responsibility for the content is on the server where it's hosted!

Does anyone else agree/disagree?

that0n3guy’s picture

that0n3guy commented

I understand what your saying and that does make sense. It probably isn't shurlys "problem" (thus feature request and not bug). But how many servers do you know that provide any "header" info when a file is directly accessed (like an image)?

alexweber’s picture

alexweber commented

Pretty much all of them! :)

You can set Etags, Expirations and all of that using .htaccess on Apache, for example! :)

quicksketch’s picture

quicksketch
he/him
commented

I'm going to agree with alexweber here. Especially considering shURLy gives a 301 redirect, which specifically is *meant* to be cacheable. It's common for web servers to cache 301 redirects for hours, days, or even weeks, since after all it's a "Moved permanently" redirect. Right now shURLy doesn't set any headers for cache lifetime on these requests, and I agree that it's really left up to the webserver how long to keep these redirects around.

quicksketch’s picture

quicksketch
he/him
commented
Status: Active » Closed (won't fix)

@alexweber is also correct in that if the image changes, it's the image's HTTP header that determines the cache lifetime of that particular image, not shURLy (which only determines the redirect). If you were to change the path entirely of the redirect (as requested in #1352010: Ability to edit an existing shortened URL, that would be applicable here. But changing the contents of an image at the same URL is not something shURLy even has the ability to affect.