== 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
IfModifiedSinceHowNot]], 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 IfModSinceTimestampProblem]]), 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 ConditionalGETIrony]] 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 /blog]] 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.