httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <>
Subject Re: mod_asis handler bug
Date Fri, 27 Jul 2001 20:52:38 GMT
On Fri, 27 Jul 2001, Bill Stoddard wrote:

> > There another bug lurking in mod_asis (reported by Ken Bruinsma in
> > IBM). We are creating the file bucket with file offset of 0.  Problem
> > is that we have already read in part of the file (the headers) a bit
> > earlier. Need to give some thought to the best way to fix this (and
> > what all the implications are).
> >
> > Perhaps pass in a -1 for offset on the apr_bucket_file_create() when
> > we want to rely on the system file pointer?  Which reminds me that I
> > still need to look at the apr_file_seek issue Cliff, Ryan and I were
> > discussing a few weeks past.
> >
> > Cliff, I am about out of time today so if you want to pursue
> > this, be my guest:-)
> But if the file is sent by sendfile, the system filepointer is
> useless.  We -must- pass the correct offset into
> apr_bucket_file_create().

Hoooo... that's fugly.  There are a few possible solutions.

(1) Keep track of the number of bytes read in from the file in
ap_scan_script_header_err() and use that as the offset when calling

(2) Have one of these "unshared file bucket" thingies as Roy suggests and
as Ryan, Bill, and I discussed a while back which relies on the system's
file pointer.  The only problem with that, as I mentioned when we last had
this discussiond, is that there's very little you can do to such a bucket
before it becomes a "shared" file bucket.  If you copy, split, etc, you
all of the sudden have to have absolute offsets and seek every time.
That could get tricky to handle.  And it would cause the kind of thing
that OtherBill initially implemented the other day when fixing up the
APR_HAS_LARGE_FILES stuff, which is to have a single apr_file_t and put it
in a whole bunch of file buckets, each with a different offset; right now,
such behavior works but is just sub-optimal performance-wise.  With
"unshared" file buckets, all of the sudden you'd have a bunch of unshared
file buckets that pointed to a single apr_file_t that really WAS shared.
Refcounting the apr_file_t causes problems as well, particularly when your
apr_file_t is APR_XTHREAD.

I kinda think we need to stick with #1.  It's way easier and avoids all
these wacky edge cases that could cause #2 to exhibit unpredictable


   Cliff Woolley
   Charlottesville, VA

View raw message