4 ms·
One problem you're probably going to run into is caches (especially caching proxies) ignoring your nocache header, causing users to see the wrong QR code. A st
by randomwalker 15y ago
One problem you're probably going to run into is caches (especially caching proxies) ignoring your nocache header, causing users to see the wrong QR code.
A standard way to avoid this is by making the image URL http://lilqr.com/qr?rand=[nonce] http://lilqr.com/qr?rand=[nonce], where you'd generate the nonce randomly on each page load. You can ignore it on the server of course.
- siavash 15y agoYour 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.
- jiaaro 15y agoYou 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)
- pronoiac 15y agoThat parameter would also be useful and needed for https urls - browsers aren't supposed to pass those along as referrers.
- siavash 15y agoThis 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!