httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject a concern
Date Tue, 28 Jan 1997 04:16:00 GMT
With Dean's new chunking code, Apache won't flush its output if there
is text waiting in the input buffer. This is better behavior,
especially if the client is pipelining requests.

However, I had a thought. I remember some discussion on http-wg a year
or so ago about how some clients, when they POST something, tack on an
extra CRLF at the end, without accounting for it in the
Content-length. Now, Apache handles this gracefully, by allowing a
request to be prepended by any number of empty lines.

However, let's imagine a client that tacked on this extra CRLF, and
also opened a persistent connection. With the current rev of the
Apache code, the server won't give the client its last block of data,
because it will see the CRLF in the input buffer, and think that the
client is sending a second request. Assuming the browser never does make
another request, it won't get its data until the keepalive timeout
times out.

Specifically, at leastNetscape Navigator 3.01 for the Macintosh
displays this particular bug.

We could do several things:

a) only activate the "better" bflush behavior if the previous request
was HTTP/1.1. Presumably all HTTP/1.1 clients are better
behaved. However, I wouldn't bet the farm on it. Given that it
wouldn't take much to make most modern HTTP clients (Netscape
included) minimally HTTP/1.1 compliant (throw in chunking support,
recognition of a few more headers, and you're done), it's possible
that at some point this may be done without fixing this bug.

b) only do it for GET requests. These can't have an entity body,
and therefore won't have this problem. This doesn't feel like the
right solution, though.

c) Add a flush into read_request_line()'s while() loop that checks for
empty lines - this way, if the empty lines are sent, the server will
flush its output. This means that these clients will have to take
a performance hit when pipelining POST requests (come to think of
it... why *would* you want to pipeline a POST request?), but I'm
comfortable with that.

d) Ignore the problem and blame the broken clients. This is a Bad
Idea, IMHO, since 80+% of the clients out there probably have this

P.S. I could have sworn one of the Netscape people (Lou Montulli, I
think) said he was going to fix this (probably by adding 2 to the
Content-length, as taking out the CRLF breaks CGI scripts when running
the CERN server, and maybe others), but I guess he never did.

Alexei Kosut <>      The Apache HTTP Server

View raw message