> Coontent-Encoding and Transfer-Encoding is fundamentally different in
> their operation far beyond the hop-by-hop vs end-to-end difference. You
> can not interchange one for the other.
> It is not safe to assume a clients accepts gzip TE only because they
> accept gzip content-encoding. For one thing the message format is
> completely different.
Yes. I'm going to try a different tack to explanation /
underpinnings.
Now I'm going to outline it by case analysis:
Protocol:
Header field cases from client:
If Accept-Encoding field is present in client request
If server or cache response contains Content-Encoding field with
encodings that are a subset of what the client accepts
Then forward response to client unchanged
Else (no helpful content-encoding field)
If uncoded response isn't available
Then forward client request to server/cache
If server/cache response contains Content-Encoding field
Then forward new response to client
Add this response to duplicate list for the object
Else (server/cache response doesn't have Content-Encoding)
Then encode client response
Add encoded response to duplicate list for the object
Send encoded response to client
Else (uncoded server response already available)
Then encode uncoded response
Add encoded response to duplicate list for the object
Send encoded response to client
Else (no Accept-Encoding in client request)
If uncoded server response already available
Forward unchanged to client
Else if coded server response already available
Then decode server response
add decoded response to duplicate list for the object
send decoded response to client
Else (no response available yet)
Then forward request to client or cache, and behave unchanged
with respect to this protocol.
Received on Thu Mar 04 2004 - 23:21:59 MST
This archive was generated by hypermail pre-2.1.9 : Thu Apr 01 2004 - 12:00:04 MST