That's 1.3K of overhead per request. I call that doing Less with More. Recruiting in HTTP headers may seem like a clever gimmick to some, but I doubt it could possibly warrant the aggregate degradation of performance. If that's what they call doing "More with Less", my reaction is hardly an urge to work with them.
Yes, I measured the size of the HTTP headers. It's not a subjective measurement. It's not 1322 bytes; it's 1275 bytes. 1322 looks like you forgot to remove the indentation that was added above for code formatting. 1275 bytes == 1.3K.
Where do you get 1275? In any case, you can't consider all of this waste. Some of it is necessary (the connection headers, content-type, some of it is a performance improvement for a subset of clients (the link headers, etc.) and a small percent is waste (X-Recruiting etc.)
I measured the headers in ajtaylor's above post. Zappos delivers different headers each time, and currently they're only giving me 599 bytes, including zero Link headers.
I agree of course that you can't consider all of it a waste. My point was just that their HTTP overhead is exceptionally large, and their superfluous headers adversely affect all of their users despite the fact that almost none of their users will ever read them.
The fact that their X-Core-Value in ajtaylor's example was "8. Do More With Less" makes them seem clueless about the real impact of HTTP overhead.
That's 1.3K of overhead per request. I call that doing Less with More. Recruiting in HTTP headers may seem like a clever gimmick to some, but I doubt it could possibly warrant the aggregate degradation of performance. If that's what they call doing "More with Less", my reaction is hardly an urge to work with them.