{"id":44358,"date":"2024-08-06T15:23:06","date_gmt":"2024-08-06T19:23:06","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=44358"},"modified":"2024-08-06T15:23:06","modified_gmt":"2024-08-06T19:23:06","slug":"netnewswire-and-conditional-get-issues","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/08\/06\/netnewswire-and-conditional-get-issues\/","title":{"rendered":"NetNewsWire and Conditional GET Issues"},"content":{"rendered":"

Brent Simmons<\/a> (Mastodon<\/a>):<\/p>\n

\n

I had thought that NetNewsWire’s conditional GET support was rock-solid — and so my first reaction was to be very surprised to learn that it’s not<\/a>!<\/p>\n

[…]<\/p>\n

When a server returns a Last-Modified header, the client should return that exact same string in follow-up requests in an If-Modified-Since header. The server then looks at the If-Modified-Since header and decides to either return a 200 plus the feed — if it has<\/em> been modified since — or return a 304 Not Modified response and an empty body.<\/p>\n

It’s the same story with the Etag header. The client should save it and return it in follow-up requests in an If-None-Match header.<\/p>\n

[…]<\/p>\n

In some cases, NetNewsWire is not picking up and saving the changed Last-Modified and Etag headers. Sometimes it does, and sometimes it keeps using whatever it already had and ignores the new ones.<\/p>\n<\/blockquote>\n

I had been meaning to file a bug about this because I’d noticed in my server logs that sometimes a lot more full requests were being served than I expected. That is, on a day when I didn’t make any posts, I would have expected the feed to be mostly cached by NetNewsWire, but it wasn’t. However, many other times it seemed like the conditions GETs were<\/em> working. Simmons found a bug that perhaps explains this.<\/p>\n\n

The other NetNewsWire issue I’ve been seeing is this one<\/a>, where sometimes it stops syncing with Feedbin until it’s restarted.<\/p>\n\n

Previously:<\/p>\n