Your right, some proxies simply ignore the Cache-Control directive. In some cases even Google Chrome handles this directive poorly, as it will serve a cached version when you use the back/forward-buttons between pages no matter what cache directive you give the image. IE and FF are flawless in this regard.
Feel free to suffix the URL with a random get-varaible, as this wont affect the service more then ensuring that proxies and cache hungry browser are less likely to cache the image.
You could also add an optional GET param that allows the user to override the url for which a QR code is generated (so ?url=... would override the default functionality of detecting the url)
This is true unless the image is served from https aswell. In that case referer is sent just as normal. I'm getting a certificate this week to serve https QRs!
Comments
Your right, some proxies simply ignore the Cache-Control directive. In some cases even Google Chrome handles this directive poorly, as it will serve a cached version when you use the back/forward-buttons between pages no matter what cache directive you give the image. IE and FF are flawless in this regard.
Feel free to suffix the URL with a random get-varaible, as this wont affect the service more then ensuring that proxies and cache hungry browser are less likely to cache the image.
You could also add an optional GET param that allows the user to override the url for which a QR code is generated (so ?url=... would override the default functionality of detecting the url)
That parameter would also be useful and needed for https urls - browsers aren't supposed to pass those along as referrers.
This is true unless the image is served from https aswell. In that case referer is sent just as normal. I'm getting a certificate this week to serve https QRs!