8 ms·
I think you're right. If you look at the standard HTTP header fields, almost all of them demand/specify information about the resource itself, its representati
by defen 16y ago
I think you're right. If you look at the standard HTTP header fields, almost all of them demand/specify information about the resource itself, its representation, or the mechanics of the transfer thereof.
The others:
Host - necessary for multiplexing over the predominant transport protocol
Date - necessary for caching
Referer - mostly useless and optional anyway
User-Agent - information about the client and essentially useless
Server - useless
And then there are the bastard children:
Cookie/Set-Cookie - used to turn HTTP into a stateful protocol
Authorization/WWW-Authenticate - used to transmit information about the relationship between the client and server.
- IgorPartola 16y agoUser-Agent is far from useless. When filling out support forms wouldn't you rather skip all the annoying questions about your OS and browser?
- defen 16y agoGood point - it's become the de-facto way of communicating client capabilities to the server.
- mjw 16y agoWell, I think you'd want to think carefully before pulling things out of HTTP and forcing HTTP to sit on top of a stateful, session-based protocol in order to achieve them. The statelessness of HTTP is one of its major strong points, making it easy to load-balance and scale, more easily compatible with a wide range of middleware, etc. The redundancy involved in repeating certain headers is a design trade-off made for a reason. There's a bunch of trade-offs here in the protocol design though, evidently. Coming at it from a security perspective seemingly leads to a different view of those tradeoffs than (say) Fielding has. If you have an application with a really pressing need for stateful session-level protocol features though -- perhaps HTTP isn't the best choice anyway?