Mail Archives: cygwin-apps/2001/11/29/15:54:27
----- Original Message -----
From: "Pavel Tsekov" <ptsekov AT syntrex DOT com>
To: <cygwin-apps AT cygwin DOT com>
Sent: Friday, November 30, 2001 4:27 AM
Subject: [setup.exe] HTTP v1.1 and persistent connections
> Hi, there! :)
>
> I've been testing the new SimpleSocket with a simple
> program I've written - it issues commands to
> FTP/HTTP servers (also proxies) and reads their
> response. While testing I've encountered a strange
> slowdown when using HTTP protocol version 1.1 (setup.exe
> uses HTTP v.1.1 in it's NetIO_HTTP class. It turned
> out that if I force the use of HTTP v.1.0 or turn off
> the persistent connection feature the slowdown is gone.
> As about the slowdown - I've noticed that the
> client reads about 8k of data and then stalls for a
> while and after that it reads the rest of the data.
The slowdown is possibly related to recieving chunk encoded data back,
which would also corrupt downloads unless you've implemented that.
From rfc 2617 (paraphrased):
HTTP/1.1 SHOULD NOT be put in the request header unless you've
implemented all the MUST, MUST NOT, and SHOULD and SHOULD NOT features
of RFC 2617.
In other words, stay with http/1.0 for now :}.
> I've read some documents and uderstand that HTTP 1.1
> introduced the persistent connection as a default
> if no otherwise specified.
Yes. However it also introduced transfer encoding and Trailers to allow
persistent connections in all cases, not just in cases where the object
size is known in advance like HTTP/1.0 does.
> Based on this I'd like to know if anyone knows about
> this slowdown and possible workarounds. If not I'd
> suggest to send additional request header on HTTP
> connection which disables the keep-alive feature
> (Connection: close).
I'd suggest the opposing tack, pass HTTP/1.0 + a
Connection/Cache-Connection header requesting persistent connection.
> Have in mind that for each package to be downloaded a
> new connection is made, so the keep-alive feature does
> not make too much sense, but the slowdown I'm talking
> about is significant. I hope this will decrease the
> overall processing time.
What the HTTP object could do is have a connection pool maintained in a
static member, and new downloads can reuse connections from that pool if
they are still open.
Rob
- Raw text -