🚀 go-pugleaf

ian@isis.demon.co.uk (Ian Smith) wrote:
>
>Anybody know what the options are for how webpage servers terminate 
>their page transmissions ?

There is either keep-alive (aka persistent connections) or no
keep-alive. HTTP/1.0 doesn't include the keep-alive features, so if
you are using that protocol the connection should close immediately
after the response has been sent.

>My attention has been drawn to www.juge.com which does something unique 
>(in my experience) when it sends it's index page. In YAN (and I'd expect 
>anything else using an httpcli based on John Washington's original) the 
>page comes through OK, but the http client still waits for more, 
>apparently not realizing that the file transmission is complete. Running 
>through a proxy server, however, it's perfectly normal, which suggests 
>that the server is sending something which rings a proxy server's bell, 
>but not the httpcli's. The question is, what ?

I have seen interoperability bugs like this before -- particularly,
Netscape Enterprise Server tries to do keep-alive with HTTP/0.9
requests. This is a bit of a disaster since HTTP/0.9 has no way to
know the data is complete other than by observing that the connection
has closed, wheras HTTP/1.* has Content-Length: headers.

To give any definitive answer, I'd have to see a dump of the complete
exchange, particularly the HTTP/x.x version tags on the requests and
responses, and the contents of any Connection: headers. Note that our
current proxy caches do not all support persistent connections.

Tony.
-- 
                 yyyyhngbgyhntthy xgdf**f.a.n.finch
                                               fanf@demon.net
                                                       dot@dotat.at

On Friday, in article
     <912159295.19386.0.nnrp-11.c30b3753@news.demon.co.uk>
     fanf@demon.net "Tony Finch" wrote:

> ian@isis.demon.co.uk (Ian Smith) wrote:
> >
> >Anybody know what the options are for how webpage servers terminate 
> >their page transmissions ?
> 
> There is either keep-alive (aka persistent connections) or no
> keep-alive. HTTP/1.0 doesn't include the keep-alive features, so if
> you are using that protocol the connection should close immediately
> after the response has been sent.

I'm talking HTTP/1.0 to the server and it's talking HTTP/1.0 back. I'm 
not sending a Keep-alive header. The server is OS2HTTPD 1.04, for 
whatever that's worth, and it's my belief that it never closes (within 
the limits of my patience :).
 
> I have seen interoperability bugs like this before -- particularly,
> Netscape Enterprise Server tries to do keep-alive with HTTP/0.9
> requests. This is a bit of a disaster since HTTP/0.9 has no way to
> know the data is complete other than by observing that the connection
> has closed, wheras HTTP/1.* has Content-Length: headers.
> 
> To give any definitive answer, I'd have to see a dump of the complete
> exchange, particularly the HTTP/x.x version tags on the requests and
> responses, and the contents of any Connection: headers. Note that our
> current proxy caches do not all support persistent connections.

The direct request packet is pretty stark:

GET / HTTP/1.0
User-Agent: YAN/2.2 (KA9Q; DOS; x86)

And the response is standard as well:

HTTP/1.0 200 OK
Date: Thursday, 26-Nov-98 00 GMT
Server: OS2HTTPD 1.04
MIME-version: 1.0
Content-type: text/html
Last-modified: Saturday, 21-Nov-98 00 GMT
Content-length: 10778

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
...
</HTML>

The page collected direct (after I've forced the connection to close) 
is identical to what Demon's proxy returns normally. I've not tried to 
force a refresh of the proxy cache.

Do Demon's proxies act on Content-Length irrespective of receiving a 
close ? If so, that would fit with what happens, because the KA9Q 
httpcli just waits for the close since the Content-Length header is 
currently discarded.

Ian.
-- 
  |  Ian Smith             |  "The Moving Finger writes;
  |  ian@isis.demon.co.uk  |   and, having writ, Moves on."