1.1 proxy interaction with 1.0 client and bad EOF behavior

consider this:

I've got a 1.1 origin server.. that has foo.html which is a static
document of 25052 bytes.. I've got a 1.0 client.. traditional response
for that document would have a Content-Length header of 25052 and the
response would be terminated by EOF.. if that connection is terminated
accidentlaly during transfer at least the client knows that 25052
bytes haven't been received (if the server was a good implementation
and included the CL header..)

now consider a 1.1 proxy in the chain.. the client sends a 1.0 request
to the 1.1 proxy.. the proxy upgrades the request to 1.1 and adds a
TE: gzip header.. the 1.1 server responds with "transfer-encoding:
gzip, chunked" and no content-length header (because its prohibited to
mix content length with non identity transfer-encoding in 4.4 ).. 

the 1.1 proxy has a dilemna with a couple of bad choices:

  a] strip the gzip as it's recvd from upstream and send what output
  you have downstream.. the response header will lack a content-length
  because the origin server was prohibited from sending the identity
  size.. when you're all done, send EOF as terminator.. if downstream
  response gets interrupted the client has no way to detect
  truncation.

  b] do store and forward, removing the the encoding and calculating
  the identity length after it has all been received. This introduces
  big time queuing delays.

both situations seem inferior to the proxy not being there at all and
it seems to be a 1.1 interaction.. think something is missing?

-P

Received on Tuesday, 28 March 2000 08:13:24 UTC