Subject: RE: transfer- and content-encoding

From: "Martin Stecher" <[email-masked]>
Date: Thu, 16 Oct 2003 13:42:29 +0200

> 
> > 	1a) OPES processors MUST support chunked transfer coding
> > 	    when handling data send by an OCP server.
> 
> IMO Yes. chunked is a good thing.
> 

IMO no for now. 
While chunked coding is a good thing for HTTP to get low latency and persistency for data that's length is not known a priori, chunked coding is not needed for OCP because it encapsulated data in DUM messages with size parameter which is the same functionality as chunked encoding (and more).

If there is a HTTP/1.0 proxy for which you want to write an OCP client (e.g. Squid), why adding chunked encoding, if it is not needed? It cannot be forwarded to the client (unless you want to update Squid to support HTTP/1.1 at the same time ;-), and so needs to be removed again.

I think from all the discussion with header correctness and OPES processor's responsibility here, it is better to not add any transfer encoding by the callout service. It is better if only the OPES processor does this for now. And transferring DUM messages into chunked encoding for HTTP is very simple.

Regards
Martin

---

From: Robert Collins <[email-masked]>
Date: Thu, 16 Oct 2003 22:35:24 +1000

On Thu, 2003-10-16 at 21:42, Martin Stecher wrote:
> While chunked coding is a good thing for HTTP to get low latency and
> persistency for data that's length is not known a priori, chunked
> coding is not needed for OCP because it encapsulated data in DUM
> messages with size parameter which is the same functionality as
> chunked encoding (and more).

Cool - thats one of the recent opes WG developments that I've only been
peripherally aware of. No need for 1a) IMO given that.

> If there is a HTTP/1.0 proxy for which you want to write an OCP client
> (e.g. Squid), why adding chunked encoding, if it is not needed? It
> cannot be forwarded to the client (unless you want to update Squid to
> support HTTP/1.1 at the same time ;-), and so needs to be removed
> again.

Funny you should mention that. I updated a one-sided (squid->server
only) TE implementation for squid circa squid 2.4, but pipeline issues
prevented robust operation with range requests, and I let the branch
lapse. We've corrected those internal issues in 3.0, and if we find a
sponsor, HTTP/1.1 for squid-3.1 will happen. 

> I think from all the discussion with header correctness and OPES
> processor's responsibility here, it is better to not add any transfer
> encoding by the callout service. It is better if only the OPES
> processor does this for now. And transferring DUM messages into
> chunked encoding for HTTP is very simple.

Sure, and conversely. Chunked after all is essentially just pascal style
string :}.

Rob

-- 
GPG key available at:
<http://members.aardvark.net.au/lifeless/keys.txt>.