Re: [Fwd: I-D ACTION:draft-decroy-http-progress-00.txt]

Henrik Nordstrom wrote:
> tis 2007-02-13 klockan 12:49 +1300 skrev Adrien de Croy:
>
>   
>> That wasn't my intention.  100 continue in practice can be hop by hop,
>> as a proxy can send it back to a client (or is this prohibited?).
>>     
>
> My understanding:
>
> RFC2616 does not intend for proxies to send 100 Continue on their own,
> only forwarding of server generated 100 Continue.
>   
fair enough - it's not particularly useful for a proxy to send a 100 
continue anyway.

> Proxies generating 100 Continue on their own messes up the HTTP version
> cache of the client and may falsely fool the client into thinking that
> the server has accepted the request and is ready to receive the
> response.
>   
understood.

I am a bit worried about the HTTP version cache though.  Do clients keep 
a record of HTTP version
responses of servers?

In this case, must the proxy always respond with the same HTTP version 
number that the server
responded with?

We breach this all the time, since we upgrade everything to HTTP/1.1 for 
the client.

For instance, we (in WinGate's HTTP proxy) do everything we can to keep 
the connection to the client
open (if client submits HTTP/1.1 request) in all cases, so

1. if we connect to a HTTP/1.0 server which sends a response with no 
content-length then we send
the data through to the client chunked, so we can keep the client-side 
connection open.  To
do this we must send it back as HTTP/1.1.  When the server closes, we 
send a final chunk.

2. if we are asked for an FTP URL, and have to act as an FTP client, we 
send data through to the
client chunked as well, this lets us maintain a session to the FTP 
server as well, which has great
performance benefits (don't need to keep connecting and logging into the 
FTP server).

we also re-chunk received chunked data from upstream (so we don't need 
to assemble entire chunks,
which would make us vulnerable to resource problems with arbitrarily big 
chunks).  this allows us to
handle chunks received up to any size.

On that note, some guidelines to web client developers on issues of 
which connection to send what
request down would be really useful.  For instance we see browsers 
sending http then ftp then CONNECT
requests down the same connection.  We see them when browsing an FTP 
server, splitting the requests
between multiple client sessions.  It would be useful if client 
developers were guided to keep the FTP
requests for the same FTP server to keep coming down the same connection 
to the proxy.

> 100 Continue and it's related delay in sending the request body has two
> purposes
>
> a) Avoiding wasting bandwidth on large request bodies which will be
> ignored by the server anyway, allowing the client to abort the request
> early withoutsending the body (by closing the connection or terminating
> chunked encoding).
>
> b) To a client receiving 100 Continue this is supposed to mean the
> request as such has been accepted by the origin server and it's now
> ready to process the body.
>   
ok, this was my understanding too.  Thanks

Adrien


> Regards
> Henrik
>

Received on Tuesday, 13 February 2007 23:04:22 UTC