Everything that the server pushes to the client is MAC'ed. If a client were to tamper with, say, the inode number, the MAC check would fail. The client continuation can optionally be encrypted and timestamped as well.

In this case too, you would need to maintain a reference to the inode server side to avoid it being unlinked. Perhaps if you're actually passing the fd to the client to hold on to, but that fd represents an awful lot of state.

To be fair, what webserver guarantees that a url it generates will be valid later on? Perhaps the inode example isn't the best, but in principle, in the framework of a stateless protocol I think this risk is not problematic. And at the end of the day, it's an impossible problem to solve perfectly - you can't keep something alive serverside just because a client wants it too. The lifespan of an inode is something you'll need to manage externally to the protocol.