On Thu, 2003-10-16 at 21:42, Martin Stecher wrote:
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).
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>.