You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@organic.com> on 1996/02/11 04:39:12 UTC
Re: patch 90g
What's the best way to test this patch? I have a compile of Randy's
1.0.2+patches build on hyperreal port 8001, but I'm not sure if
keepalives are working or not. I have set
KeepAlive 25
KeepAliveTimeout 30
in httpd.conf to look for it. I tried the following:
telnet bong.com 8001
GET / HTTP/1.0
Connection: Keep-Alive
And I got back the document, with a connection closed. Is there
something I'm missing?
Brian
On Fri, 9 Feb 1996, Alexei Kosut wrote:
> On Fri, 9 Feb 1996, Roy T. Fielding wrote:
>
> > Hmmm, nothin like experimentation. Did you try "Warning: your browser
> > *really* sucks"?
>
> I tried everything :)
>
> > I'll bet it is a global variable that gets set by the amount of data
> > on the first read (i.e., the headers) and doesn't get reset before
> > the next one. Either that, or they are reading the entire file in one
> > read and just forgetting to check the rest of the buffer (post-header
> > processing) before trying to do another blocking read. I wonder what
> > would happen if you did a flush after sending the headers and
> > before sending the data? Maybe with a delay in between?
>
> Wow... you're a genius. Can I say that? Anyhow, I went and added a
> fflush() to the end of send_http_header(), and viola, it works. Without
> header or size manipulation, nor user-agent checking either.
>
> Patch 90f (those letters are getting up there) has been put in
> httpd/patches/for_Apache_1.0.2 (Brian gave me a hyperreal account - wasn't
> that nice of him?). It seems to work. Yipee.
>
> --/ Alexei Kosut <ak...@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
> ----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
> The viewpoints expressed above are entirely false, and in no way
> represent Alexei Kosut nor any other person or entity. /--------------
>
>
>
>
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: patch 90g
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Sat, 10 Feb 1996, Brian Behlendorf wrote:
> It's still a good thing to document. I.e. "Any response which does not
> have a known content-length before content is actually sent will
> terminate a persistant connection. I.e., CGI script output, HTML
> documents with server-side includes, etc." (any others?)
Directory listings.
> The crucial question to me, though, is: if Netscape is configured to open
> 4 simultaneous connections, and it opens 4 to a page with 3 inlined
> images, those 4 objects will be requested as 4 separate connections, not
> one keep-alive connection through which 4 objects pass, right? I guess
> that suggests that keepalive is only beneficial if the number of inlined
> objects is greater than the number of allowed simultaneous connections.
> Or am I missing something? I wish I could see what the traffic between
> netscape and the server looked like, raw....
So do we all... Yeah, I've wondered the same thing myself. For all we
know, Netscape just closes the connection right afterwards, anyway. At any
rate, I seem to recall reading sometime on http-wg that persistent
connections really began to get useful once the request timeout went past
about 10 seconds, which would be more people clicking on links than
loading images.
> Hmm, one thing that would help is if the httpd process PID could be
> logged in mod_log_config.
Yeah. Maybe. Though it could be misleading. Since two requests on the
same connection could *look* the same as two requests on different
connections if they both happened to get the same child.
> It's just that having a multiplicity of responses which force a
> persistant-connection termination is a bad thing... the more there arem
> the less useful persistant-connections is. We should identify them and
> try to reconcile them.
Well, having some persistent connections is more useful than having none.
And it doesn't lie about it - it doesn't send a Connection: Keep-Alive,
and then just close it at the end without warning. If it did that, it'd
be bad, but as it is, it's still better than nothing.
> You just can't remove something from a to-do list without adding three
> others, huh? :)
Guess not. :)
--/ Alexei Kosut <ak...@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------
Re: patch 90g
Posted by Brian Behlendorf <br...@organic.com>.
On Sat, 10 Feb 1996, Alexei Kosut wrote:
> On Sat, 10 Feb 1996, Brian Behlendorf wrote:
>
> > Ah, because it's a server-parsed document? Hmm, that's a problem, SSI's
>
> Yes.
>
> > are so widespread that it should at least be noted in the documentation
> > for the persistant-connection Apache implementation. Eek. Any way to
>
> I don't think there's any noting needed, really. I mean, it's an entirely
> behind-the-scenes thing. Unless someone's client is sending Connection:
> Keep-Alive, but doesn't really support it, neither the user of the
> browser nor the server will ever know that Keep-Alive is being used, save
> for a slight speed-up.
It's still a good thing to document. I.e. "Any response which does not
have a known content-length before content is actually sent will
terminate a persistant connection. I.e., CGI script output, HTML
documents with server-side includes, etc." (any others?)
The crucial question to me, though, is: if Netscape is configured to open
4 simultaneous connections, and it opens 4 to a page with 3 inlined
images, those 4 objects will be requested as 4 separate connections, not
one keep-alive connection through which 4 objects pass, right? I guess
that suggests that keepalive is only beneficial if the number of inlined
objects is greater than the number of allowed simultaneous connections.
Or am I missing something? I wish I could see what the traffic between
netscape and the server looked like, raw....
Hmm, one thing that would help is if the httpd process PID could be
logged in mod_log_config.
It's just that having a multiplicity of responses which force a
persistant-connection termination is a bad thing... the more there arem
the less useful persistant-connections is. We should identify them and
try to reconcile them.
You just can't remove something from a to-do list without adding three
others, huh? :)
> > fix that? I know chunked-transfer-encoding is coming as the long term
> > solution to indeterminante-length-documents in persistant connections,
> > but it'd be nice if there was some way for the length of
> > non-CGI-including SSI's to be determined. Though I suppose that can't be
> > done without at least double-scanning the document.
>
> Right. Though we could certainly do that. CERN puts Content-lengths on
> *everything* under 50k (this is settable, and doesn't apply to files
> where the size is known beforehand), by buffering it until it's done.
This sounds reasonable. People who can't wait for 50K to be generated by
the CGI before pumping them out can use nph- scripts. What do others
think? I'd like that to be configurable.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: patch 90g
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Sat, 10 Feb 1996, Brian Behlendorf wrote:
> Ah, because it's a server-parsed document? Hmm, that's a problem, SSI's
Yes.
> are so widespread that it should at least be noted in the documentation
> for the persistant-connection Apache implementation. Eek. Any way to
I don't think there's any noting needed, really. I mean, it's an entirely
behind-the-scenes thing. Unless someone's client is sending Connection:
Keep-Alive, but doesn't really support it, neither the user of the
browser nor the server will ever know that Keep-Alive is being used, save
for a slight speed-up.
> fix that? I know chunked-transfer-encoding is coming as the long term
> solution to indeterminante-length-documents in persistant connections,
> but it'd be nice if there was some way for the length of
> non-CGI-including SSI's to be determined. Though I suppose that can't be
> done without at least double-scanning the document.
Right. Though we could certainly do that. CERN puts Content-lengths on
*everything* under 50k (this is settable, and doesn't apply to files
where the size is known beforehand), by buffering it until it's done.
--/ Alexei Kosut <ak...@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------
Re: patch 90g
Posted by Brian Behlendorf <br...@organic.com>.
On Sat, 10 Feb 1996, Alexei Kosut wrote:
> On Sat, 10 Feb 1996, Brian Behlendorf wrote:
> > telnet bong.com 8001
> > GET / HTTP/1.0
> > Connection: Keep-Alive
> >
> > And I got back the document, with a connection closed. Is there
> > something I'm missing?
>
> Yes. That document has no Content-length.
Ah, because it's a server-parsed document? Hmm, that's a problem, SSI's
are so widespread that it should at least be noted in the documentation
for the persistant-connection Apache implementation. Eek. Any way to
fix that? I know chunked-transfer-encoding is coming as the long term
solution to indeterminante-length-documents in persistant connections,
but it'd be nice if there was some way for the length of
non-CGI-including SSI's to be determined. Though I suppose that can't be
done without at least double-scanning the document.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: patch 90g
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Sat, 10 Feb 1996, Brian Behlendorf wrote:
> telnet bong.com 8001
> GET / HTTP/1.0
> Connection: Keep-Alive
>
> And I got back the document, with a connection closed. Is there
> something I'm missing?
Yes. That document has no Content-length.
--/ Alexei Kosut <ak...@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC
----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------