> I don't get what he fails to understand: if the back function obeyed expiration headers, then going back could potentially reload the page, potentially causing a re-GET or even a re-POST.
There's already behaviour in place in most (all?) browsers to cover this case, at least for POST. When you go back to a page with had form data attached to the request, they'll ask you whether to re-submit the form.
This doesn't happen for GET, but then you probably shouldn't be using GET for data anyway.
Honestly, they shouldn't re-prompt IMHO — they should only do that on a reload — rather, they should just display the page as it was, which is what I expect when I hit back.
I agree. This would greatly frustrate users on quick-feed news sites and social media who are hoping to find that article or post they were just reading to find it now gone because the sites algorithm marked it as 'read'.
I have this problem all the time on YouTube. I'll instinctively click through to subscriptions but when that is loading I'll notice a recommended video that looks interesting. But then hitting back it's gone because YouTube has reshuffled the recommendations
There's already behaviour in place in most (all?) browsers to cover this case, at least for POST. When you go back to a page with had form data attached to the request, they'll ask you whether to re-submit the form.
This doesn't happen for GET, but then you probably shouldn't be using GET for data anyway.