Re: transfer encoding & trailers

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Sunday, January 14, 2001 6:39 AM
Subject: Re: transfer encoding & trailers

> Robert Collins wrote:
>
> > We can send trailers quite happily. RFC 2616 requires clients to indicate their understanding of trailers with
> > TE: trailers
> > unless the fields going in the trailer are 100% optional metadata.
>
> 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.

> > So we can fully support digest message body signing (that's all
> > trailers are for).
>
> 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 :].

> > What we cannot do is recieve and use trailers from origin or
> > upstream servers - so we don't offer a TE: trailers in our requests.
>
> Unless we agree on sending the data non-recoded to the client.

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.

If you are referring to optimising out the memcpy's and so forth in getting the data to client_side, then that's different. I
already posted up a few concepts to the list last week.

> > What's more difficult is getting to the client side HttpReply
> > to write those headers.
>
> We basically needs to rewrite the request/reply chain anyway, so don't
> worry to much about the current code. Instead concentrate on what is
> required to be able to perform the transforms that might be needed.
>
>
> Things which we need to decide on
> * Where to perform TE decoding
> * When to do it
> * If requests should be upgraded to add things like cache-cache
> compression

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.

Rob
Received on Sat Jan 13 2001 - 15:28:51 MST