Re: transfer encoding & trailers

Robert Collins wrote:

> > So we kan quite happily degrade the protocol to HTTP/1.1 without
> > trailers if needed.
>
> Upgrade to 1/1 I think you mean? Yes you do not have to accept
> trailers to be HTTP/1.1 compliant. I don't think it's even a SHOULD
> to support them. What to do if you support them is another matter.

No, Downgrade from HTTP/1.1 with trailers to HTTP/1.1 without trailers.

> > Trailers can also be used for meta-data. One good example is
> > Last-Modified on objects generated from multiple sources, for eample
> > server-side include.
>
> Agreed. I'd like to code in trailer support :].

I'd say we pretty much need to if we want to be able to make good use of
objects received with chunked encoding. As I said chunked encoding
(outside digest authentication) is mostly used when the server does not
know everything when it starts to generate the reply. And here much of
the important meta data is put in the trailer. Without support for
trailers we most likely cannot cache those objects.

However, when upgrading HTTP/1.0 requests we can disable trailers and
put our faith in that the origin server will provide us with the needed
trailer anyway.. this way the damage will be limited to at least no
worse than if the downstream had contacted the origin directly, and we
can still cache the object.

> I don't see how that ties in. Sending non-recoded data to the
> client will break RFC 2616. (Specifically we must upgrade all
> requests we recieve to the highest HTTP version we support -
> HTTP/1.1. Now HTTP/1.1 requires us to support recieving chunked
> transfer codings. We cannot send that through to a HTTP/1.0 client.
> OOPS.

Right. I forgot 2 MUST there.. (MUST upgrade, MUST accept chunked).
Stupid me.

Wonder why the "MUST upgrade request" requirement is there. I don't see
the need for that one being a MUST, more like a SHOULD.

> RFC 2616: requests MUST be upgraded. As soon as we say "HTTP/1.1"
> in an upgraded request, we expect cache-cache transfer codings.
> Not doing compression at that point seems silly. Also with Delta
> based transfer codings getting stablised (ie rproxy) I think it
> would be a really good idea to be able to support such things.

I meant within HTTP/1.1 to indicate to the upstream that we want to do
cache-cache codings.

But I think I agree with you now in that TE should be decoded early, at
least for chunked encoding. We must do so anyway to be able to parse the
HTTP stream, and only forward the data parts makes sense (it is easily
re-chunked at the client side if needed).

/Henrik
Received on Sat Jan 13 2001 - 16:39:25 MST