- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 18 Nov 97 15:41:48 PST
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I am generally pursuaded that Roy is right, that we should
be using both Content-Encoding and Transfer-Encoding, and
that Range selections should be applied after Content-Encoding
and before Transfer-Encoding. I also think that Henrik's
proposal for Accept-Transfer is generally a good one.
But there are still a few loose ends to tie up.
First of all, Henrik wrote (regarding Transfer-Encoding):
1) They don't have the same scope - one is end-to-end and the other is
hop-by-hop. As the message length changes, it can only be used through
proxies that know about that particular encoding. In other words: the
stupidest link in the chain decides the encoding.
More specifically, because Transfer-Encoding and Accept-Transfer are
hop-by-hop fields, a response that flows through an HTTP/1.0 proxy
can't have a Transfer-encoding (such as on-the-fly compression)
for the two hops that involve that proxy.
This is sad, but it does avoid a big problem with the use of new
compression algorithms (or other codings): the possibility that such
responses might be improperly cached by an HTTP/1.0 shared cache, and
then delivered to a client that doesn't understand them. It might
also provide some incentive for people to upgrade their 1.0 proxies
to 1.1, since it's usually the proxy operator who is paying for
the bandwidth on at least one side of the proxy.
However, there is (at least) one more slight problem with the
hop-by-hop nature of Transfer-Encoding. Section 15.1.1 (End-to-end
and Hop-by-hop Headers) currently says:
For the purpose of defining the behavior of caches and non-
caching proxies, we divide HTTP headers into two categories:
. End-to-end headers, which must be transmitted to the
ultimate recipient of a request or response. End-to-end
headers in responses must be stored as part of a cache
entry and transmitted in any response formed from a
cache entry.
. Hop-by-hop headers, which are meaningful only for a
single transport-level connection, and are not stored
by caches or forwarded by proxies.
The following HTTP/1.1 headers are hop-by-hop headers:
. Connection
. Keep-Alive
. Public
. Proxy-Authenticate
. Transfer-Encoding
. Upgrade
[NOTE TO JIM GETTYS: the "must"s in that passage should be MUSTs,
right?]
The most simplistic interpretation of the phrase "Hop-by-hop headers
... and are not stored by caches or forwarded by proxies" implies
that a transfer-encoding has to be removed by a proxy cache before
the response is stored.
Clearly, if a proxy supports a transfer-coding, and both the
inbound server and the outbout client also support the same coding,
then it would be a real waste of CPU time to do this for compressed
transfer-codings. So I think that after
. Hop-by-hop headers, which are meaningful only for a
single transport-level connection, and are not stored
by caches or forwarded by proxies.
we should add:
Note: a proxy or cache need not actually delete a
hop-by-hop header in a case where its external
behavior would be equivalent to deleting the header
and then adding it again. For example, a proxy
receiving a response with a non-identity
transfer-coding need not remove that coding, and the
corresponding Transfer-Encoding header field, unless
the response is being sent to a client that has not
sent an appropriate Accept-Transfer header.
--------
The other problem that we may need to clarify is that if
a transfer-coding (e.g., "compress") is used with a Range response
containing multiple ranges, then should the transfer-coding apply
to the entire "multipart/byteranges" body, or just to the
parts individually?
It seems possible to leave this up to the server, and let the
server choose the most appropriate option for a given response,
rather than to try to embed the choice in the protocol specification.
But this means that a client sending both a multi-part Range
request and a non-identity "Accept-Transfer:" would have to be
able to grok two different forms of response.
E.g., combining the example in 19.2 with "compress", the client might get
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000
Transfer-Encoding: compress
...the first range..., compressed
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000
Transfer-Encoding: compress
...the second range, compressed
--THIS_STRING_SEPARATES--
or it might get
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
Transfer-Encoding: compress
.... compressed form of the multipart/byteranges type .....
Note that section 3.7.2 (Multipart Types) seems to allow the first
form:
In HTTP, multipart body-parts MAY contain header fields
which are significant to the meaning of that part.
If this makes sense to people, then I would add this paragraph to the
end of section 3.7.2 (Multipart Types).
If a client has indicated its acceptance of one or more
non-identity transfer-codings (using the Accept-Tranfser
header, section XXX) and it is otherwise appropriate to use a
multipart type, the server MAY either apply a transfer-coding
to the entire message-body, and MAY apply a transfer-coding to
one or more of the individual body-parts.
-Jeff
Received on Tuesday, 18 November 1997 15:48:25 UTC