> For example: he says to remove the User-Agent header. Without that https://www.dropbox.com/downloading wouldnt work (where they can give you the correct download and show you pictures of how to access/install it).
There is no good reason to do UA sniffing. That page could simply provide you one of 3 (or more) options to select.
> Furthermore, the Date header is very successfully used for caching operations in many cases.
Date headers are not useful for that purpose. Expiration would be based on the time of the UA, not the one given by a server.
> Moreover, it suggests problems that I see (such as the cookie kludge) but not a good replacement/solution for it.
The use of a session identifier, or to use client-side storage until it is needed. The session identifier is not the best solution, but it is a step towards a better system, I believe. Eventually I would like to see it removed.
> However, they cannot trust the clients and so have to resort to nasty things like hmac'ing the cookies and more easy to mess up security details.
You should never trust anything given to you from a client. If I send you a product list, that product list should be opaque ids. The session should be ephemeral and not matter anyway, so there is no reason for it to be signed.
> There is no good reason to do UA sniffing. That page could simply provide you one of 3 (or more) options to select.
So, giving people the correct file instead of making them know what they need (which many people dont... especially if it is browser specific) is not a good reason? What if a server wants to provide a client with native order endianess (for RPC for example), that shouldnt be allowed?
> Date headers are not useful for that purpose. Expiration would be based on the time of the UA, not the one given by a server.
Tell that to my browser which countless times doesnt fetch a new file because it has a cached copy. Furthermore, if the headers are stored with the cached copy, there is no server/client time problem because you can calculate the difference between server time and client time.
> The session should be ephemeral and not matter anyway, so there is no reason for it to be signed.
This is correct in idea, but not in practice. Often times, the server isnt a single server, but rather a set of load-balanced servers. When this happens, it is hard to keep track of client state because a client might get load-balanced to another machine on its next request. Therefore, client state is kept with the client (and signed to make sure that it is legitimate). This sort of behavior has become necessary, although can be better dealt with with some sort of standard (esp. to ensure the protection of the cookie et cetera).
> So, giving people the correct file instead of making them know what they need (which many people dont... especially if it is browser specific) is not a good reason?
No, it is not. Give the user the option of what to download. What if I want the Windows version even though I'm running Linux?
> What if a server wants to provide a client with native order endianess (for RPC for example), that shouldnt be allowed?
RPC should have a standard byte order defined.
> Tell that to my browser which countless times doesnt fetch a new file because it has a cached copy.
That's based on cache control, which isn't affected by the Date header sent by the server.
> Often times, the server isnt a single server, but rather a set of load-balanced servers.
I know. I've set these systems up before. There shouldn't be anything of consequence stored on the client. So what if someone changes the session ID? Does it really matter? If someone has someone else's ID they probably have the signature too. If it's a random search, using random ids goes a very long way. Also, beyond sessions, there doesn't need to be a session. There are now ways to store data on the client that don't require sending it back and forth to the server on every request.
There is no good reason to do UA sniffing. That page could simply provide you one of 3 (or more) options to select.
> Furthermore, the Date header is very successfully used for caching operations in many cases.
Date headers are not useful for that purpose. Expiration would be based on the time of the UA, not the one given by a server.
> Moreover, it suggests problems that I see (such as the cookie kludge) but not a good replacement/solution for it.
The use of a session identifier, or to use client-side storage until it is needed. The session identifier is not the best solution, but it is a step towards a better system, I believe. Eventually I would like to see it removed.
> However, they cannot trust the clients and so have to resort to nasty things like hmac'ing the cookies and more easy to mess up security details.
You should never trust anything given to you from a client. If I send you a product list, that product list should be opaque ids. The session should be ephemeral and not matter anyway, so there is no reason for it to be signed.