You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1997/01/28 21:30:06 UTC
304 and keepalive bug
On Tue, 28 Jan 1997, Dean Gaudet wrote:
> I've discovered what looks like a bug elsewhere -- when we send
> back a 304 we also send a Connection: close (presumably because
> there's no Content-Length). So when netscape is verifying a page like
> <http://www.arctic.org/~dgaudet/all-icons> it has to open a connection
> for each GET If-Modified-Since. Protocol cops?
I tried with the patch below included and navigator was able to do
keepalive properly on 304 responses. So this is definately an apache bug.
I'm not sure of the correct solution, that set_keepalive if() statement is
a monster mess.
Incidentally, the difference on the wire is a difference of 744 packets
versus 211.
Dean
Index: http_protocol.c
===================================================================
RCS file: /export/home/cvs/apache/src/http_protocol.c,v
retrieving revision 1.93
diff -c -3 -r1.93 http_protocol.c
*** http_protocol.c 1997/01/26 01:15:13 1.93
--- http_protocol.c 1997/01/28 20:26:02
***************
*** 216,222 ****
else if (r->server->keep_alive && (!r->server->keep_alive_max ||
(r->server->keep_alive_max > r->connection->keepalives)) &&
(r->server->keep_alive_timeout > 0) &&
! (r->header_only || length || tenc ||
((r->proto_num >= 1001) && (r->byterange > 1 || (r->chunked = 1)))) &&
(!find_token(r->pool, conn, "close")) &&
((ka_sent = find_token(r->pool, conn, "keep-alive")) ||
--- 216,222 ----
else if (r->server->keep_alive && (!r->server->keep_alive_max ||
(r->server->keep_alive_max > r->connection->keepalives)) &&
(r->server->keep_alive_timeout > 0) &&
! (r->status == USE_LOCAL_COPY || r->header_only || length || tenc ||
((r->proto_num >= 1001) && (r->byterange > 1 || (r->chunked = 1)))) &&
(!find_token(r->pool, conn, "close")) &&
((ka_sent = find_token(r->pool, conn, "keep-alive")) ||
Re: 304 and keepalive bug
Posted by Chuck Murcko <ch...@topsail.org>.
Alexei Kosut wrote:
>
> On Tue, 28 Jan 1997, Dean Gaudet wrote:
>
> > I tried with the patch below included and navigator was able to do
> > keepalive properly on 304 responses. So this is definately an apache bug.
> > I'm not sure of the correct solution, that set_keepalive if() statement is
> > a monster mess.
>
> It's not a bug - Apache's not required to support persistent
> connections at all. On the other hand, it's a nice feature, and I can
> see no reason why Apache shouldn't keep persistent connections alive.
>
> +1 on your patch.
>
+1 also. A separate mechanism would be needed to deal with the bodied
messages. The fact that error messages in Apache can be customized makes
that a real headache.
--
chuck
Chuck Murcko
The Topsail Group, West Chester PA USA
chuck@topsail.org
Re: 304 and keepalive bug
Posted by Dean Gaudet <dg...@arctic.org>.
Ah ok I feel better about my patch then.
Dean
On Wed, 29 Jan 1997, Alexei Kosut wrote:
> On Wed, 29 Jan 1997, Dean Gaudet wrote:
>
> > But is my patch really the best way to do it? Shouldn't all 300, 400, and
> > 500 responses allow keepalive? It's only 200s that don't have
> > content-length (and can't chunk encode) that I can think of which should
> > send Connection: close. But I've never looked into this part of the
> > server very much.
>
> All error responses *should*. The problem has nothing to do with that,
> but with the way Apache creates the message bodies: there's no way to
> determine a content-length for these responses without rewriting all
> that code. No one ever bothered to do so. 304 doesn't have this
> problem because it's bodyless.
>
> And, of course, some other changes would have to be made; for example,
> if I POST to a non-POSTable file, the server will return an error, but
> the POST data is still sitting there in the input stream, and if we
> maintained a persistent connection here, that'd be a problem. And, of
> course, you run into other problems here: mod_cgi, for example, can
> return an error both before and after it reads POST data. Currently,
> the server has no way of knowing this. And what if the error is
> returned in the middle of reading in the data? You'd need some more
> functionality in the *_client_block functions, and then tap into that
> when creating the error.
>
> In other words, there's no fundamental reason why we shouldn't
> establish persistent connections for all responses, there are just
> some things that need to be done that no one has.
>
> --
> ________________________________________________________________________
> Alexei Kosut <ak...@nueva.pvt.k12.ca.us> The Apache HTTP Server
> URL: http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
>
>
Re: 304 and keepalive bug
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Wed, 29 Jan 1997, Dean Gaudet wrote:
> But is my patch really the best way to do it? Shouldn't all 300, 400, and
> 500 responses allow keepalive? It's only 200s that don't have
> content-length (and can't chunk encode) that I can think of which should
> send Connection: close. But I've never looked into this part of the
> server very much.
All error responses *should*. The problem has nothing to do with that,
but with the way Apache creates the message bodies: there's no way to
determine a content-length for these responses without rewriting all
that code. No one ever bothered to do so. 304 doesn't have this
problem because it's bodyless.
And, of course, some other changes would have to be made; for example,
if I POST to a non-POSTable file, the server will return an error, but
the POST data is still sitting there in the input stream, and if we
maintained a persistent connection here, that'd be a problem. And, of
course, you run into other problems here: mod_cgi, for example, can
return an error both before and after it reads POST data. Currently,
the server has no way of knowing this. And what if the error is
returned in the middle of reading in the data? You'd need some more
functionality in the *_client_block functions, and then tap into that
when creating the error.
In other words, there's no fundamental reason why we shouldn't
establish persistent connections for all responses, there are just
some things that need to be done that no one has.
--
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us> The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Re: 304 and keepalive bug
Posted by Dean Gaudet <dg...@arctic.org>.
But is my patch really the best way to do it? Shouldn't all 300, 400, and
500 responses allow keepalive? It's only 200s that don't have
content-length (and can't chunk encode) that I can think of which should
send Connection: close. But I've never looked into this part of the
server very much.
Dean
On Tue, 28 Jan 1997, Alexei Kosut wrote:
> On Tue, 28 Jan 1997, Dean Gaudet wrote:
>
> > I tried with the patch below included and navigator was able to do
> > keepalive properly on 304 responses. So this is definately an apache bug.
> > I'm not sure of the correct solution, that set_keepalive if() statement is
> > a monster mess.
>
> It's not a bug - Apache's not required to support persistent
> connections at all. On the other hand, it's a nice feature, and I can
> see no reason why Apache shouldn't keep persistent connections alive.
>
> +1 on your patch.
>
> --
> ________________________________________________________________________
> Alexei Kosut <ak...@nueva.pvt.k12.ca.us> The Apache HTTP Server
> URL: http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
>
>
Re: 304 and keepalive bug
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Tue, 28 Jan 1997, Dean Gaudet wrote:
> I tried with the patch below included and navigator was able to do
> keepalive properly on 304 responses. So this is definately an apache bug.
> I'm not sure of the correct solution, that set_keepalive if() statement is
> a monster mess.
It's not a bug - Apache's not required to support persistent
connections at all. On the other hand, it's a nice feature, and I can
see no reason why Apache shouldn't keep persistent connections alive.
+1 on your patch.
--
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us> The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/