derp typo
no ETag for dynamically-compressed entities

A dynamically-compressed (content-encoding) response no longer keeps its original (pre-compression) ETag.

Old Example:
---
Two user-agents, A and B, connect through a caching proxy P to server S.

1. A sends a request to P:
```
GET / HTTP/1.1
Accept-Encoding: gzip
```

2. No caching stuff, so P forwards to S, and S replies:
```
200 OK
ETag: "x"
Content-Encoding: gzip
Vary: Accept-Encoding

..gzip-data..
```
Which P caches, and sends back to A.

3. B sends a request to P:
```
GET / HTTP/1.1
Accept-Encoding: deflate
```

4. P has a version of "/", but because of the Vary header and the different Accept-Encoding, it knows it can't use the cached value; so it forwards to S[1], and S replies:
```
200 OK
ETag: "x"
Content-Encoding: deflate
Vary: Accept-Encoding

..deflated-data..
```
Which P _probably_ caches, and _hopefully_ sends the deflated-data back to B.[2]

5. A sends a new request to P:
```
GET / HTTP/1.1
If-None-Match: "x"
Accept-Encoding: gzip
```

6. P either ignores the Vary header, sending whatever it has cached to A; or honours the Vary header, and forwards to S, wash, rinse, repeat.

[1] Unless it doesn't, in which case it sends the gzip-encoded data to B, which expected deflate-encoded data.
[2] But it might not, because the response ETag matches the cached one, even though the entity body is different. If it's clever, it'll even cache B's response separately from A's, because of the Vary header; but who knows...