Giving in: pragmatic If-Modified-Since
handling for Tiny Tiny RSS
I wrote yesterday about how Tiny Tiny RSS drastically mishandles
generating If-Modified-Since
headers for conditional GETs, but I didn't say anything about what my
response to it is. DWiki insists on strict equality checking between
If-Modified-Since
and the Last-Modified
timestamp (for good
reasons), so Tiny Tiny RSS was basically
doing unconditional GETs all the time.
I could have left the situation like that, and I actually considered it. Given the conditional GET irony I was never saving any CPU time on successful conditional GETs, only bandwidth, and I'm not particularly bandwidth constrained (either here or potentially elsewhere; 'small' bandwidth allocations on VPSes seem to be in the multiple TBs a month range by now). On the other hand, these requests were using up quite a lot of bandwidth because my feeds are big and Tiny Tiny RSS is quite popular, and that unnecessary bandwidth usage irritated me.
(Most of the bandwidth that Wandering Thoughts normally uses is in feed requests, eg today 87% of the bandwidth was for feeds.)
So I decided to give in and be pragmatic. Tiny Tiny RSS expects you
to be doing timestamp comparisons for If-Modified-Since
, so I added
a very special hack that does just that if and only if the user agent
claims to be some version of Tiny Tiny RSS (and various other conditions
apply, such as no If-Not-Modified
header being supplied). Looking at
my logs this appears to have roughly halved the bandwidth usage for
serving feeds, so I'm calling it worth it at least for now.
I don't like putting hacks like this into my code (and it doesn't fully solve Tiny Tiny RSS's problems with over-fetching feeds either), but I'm probably going to keep it. The modern web is a world full of pragmatic tradeoffs and is notably lacking in high-minded purity of implementation.
|
|