httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rici Lake <>
Subject AP_MODE_EATCRLF considered indigestible
Date Fri, 15 Apr 2005 00:50:09 GMT
I was taking a look at the implementation of the renamed (but still 
misleading) AP_MODE_EATCRLF, in an attempt to figure out what a 
conforming input filter ought to do if it's handed that mode.

Some comments:

1) The loop in server/core_filters.c:226
             while (c < str + len) {
                 if (*c == APR_ASCII_LF)
                 else if (*c == APR_ASCII_CR && *(c + 1) == APR_ASCII_LF)
                     c += 2;
                     return APR_SUCCESS;

If the last character of the bucket being examined is an ASCII CR, this 
will first look beyond the end of the bucket's buffer to check for an 
LF; assuming it doesn't find one in the random byte it looks at, it 
will then return APR_SUCCESS even if the following bucket (if any) 
started with an LF. So that's presumably wrong on two counts.

2) The only place I can see that this mode is actually used is in 
modules/http/http_request.c, where it is used to decide whether or not 
to flush the filter chain before logging. the comment at line 226 of 
that file seems reasonable:
      * We want to flush the last packet if this isn't a pipelining 
      * *before* we start into logging.  Suppose that the logging causes 
      * lookup to occur, which may have a high latency.  If we hold off 
      * this packet, then it'll appear like the link is stalled when 
      * it's the application that's stalled.
Presumably that's true whether or not the connection is pipelining; why 
is it acceptable to make a link appeared stalled in a pipelining 
connection but not a keepalive connection?

3) In general, AP_MODE_EATCRLF seems to me to be a tight coupling 
between a particular function in http_request.c and a particular input 
filter (core_input_filter). The expense is added complexity for every 
input filter.

Removing the mode altogether would mean that either every request was 
flushed through the filter chain even in pipelining mode, or that 
ap_process_request would have to come up with some other way of 
detecting pending input. Unless there is good empirical evidence of the 
pipelined filter flush leading to performance problems, the first of 
these options would seem attractive.

I presume the main reason to avoid flushing between pipelined requests 
would be a sequence of WebDAV requests with short responses, although 
there is also the common case of browsers pipelining a request for 
favicon.ico before the page actually requested by the user. But are the 
responses so short that the flush would have an enormous impact? The 
favicon.ico response from a random iconless server comes out at 458 
bytes, for example.

View raw message