You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU> on 2000/06/16 04:45:03 UTC
reading config file one byte at a time
I haven't caught up with my mail yet, but found this while teaching
an in-house class on Apache debugging tricks a couple hours ago.
If you do an
strace -f ./httpd -d /home/apache/serverroot >& outfile
(or truss, depending on your system OS) you will see the following
open("/home/fielding/ws/test/conf/httpd.conf", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=33482, ...}) = 0
read(3, "#", 1) = 1
read(3, "\n", 1) = 1
read(3, "#", 1) = 1
read(3, " ", 1) = 1
read(3, "B", 1) = 1
read(3, "a", 1) = 1
read(3, "s", 1) = 1
read(3, "e", 1) = 1
read(3, "d", 1) = 1
read(3, " ", 1) = 1
...
...
...
Needless to say, that sucks. I figure it is a degenerate case of the
new iol code or saferead or something like that. I'll check into it
later tonight if I get a chance (laundry night).
This is on Linux, though it probably isn't OS-specific.
....Roy
Re: reading config file one byte at a time
Posted by "Jeff Trawick (httpd)" <tr...@ibm.net>.
> Date: Fri, 16 Jun 2000 02:04:05 -0400
> From: Manoj Kasichainula <ma...@io.com>
>
> On Fri, Jun 16, 2000 at 04:55:22AM -0000, Jeff Trawick (httpd) wrote:
> > I think the file I/O stuff could use a thorough cleanup in both the
> > design and implementation (e.g., doc says you can read 100 bytes *and*
> > get APR_EOF reported; this is not helpful to apps and is contrary to
> > existing APIs; luckily at least some of the code doesn't seem to do
> > this).
>
> I'm unclear on what you like. It's definitely true that some code does
> not follow that spec. Do you dislike that state of affairs, or do you
> dislike the spec?
>
> I think returning APR_EOF as well as 100 bytes is perfectly clear. It
> means that you've read 100 bytes and have also hit the end of the
> file. :) Reading 100 bytes and APR_SUCCESS means that you're still in
> the middle of the file, and reading 100 bytes and APR_EIO means that
> there was an I/O error after reading 100 bytes.
I don't have any problem understanding the concept. I think it is
unexpected to people who have programmed with stdio or OS-level
calls on most operating systems (in other words, everyone that would
use APR). If I ask for 1024 bytes and only 128 remain, I expect to
get rc=0,nbytes=128 on one call and rc=APR_EOF,nbytes=0 on the next.
Jeff
Re: reading config file one byte at a time
Posted by Manoj Kasichainula <ma...@io.com>.
On Fri, Jun 16, 2000 at 04:55:22AM -0000, Jeff Trawick (httpd) wrote:
> I think the file I/O stuff could use a thorough cleanup in both the
> design and implementation (e.g., doc says you can read 100 bytes *and*
> get APR_EOF reported; this is not helpful to apps and is contrary to
> existing APIs; luckily at least some of the code doesn't seem to do
> this).
I'm unclear on what you like. It's definitely true that some code does
not follow that spec. Do you dislike that state of affairs, or do you
dislike the spec?
I think returning APR_EOF as well as 100 bytes is perfectly clear. It
means that you've read 100 bytes and have also hit the end of the
file. :) Reading 100 bytes and APR_SUCCESS means that you're still in
the middle of the file, and reading 100 bytes and APR_EIO means that
there was an I/O error after reading 100 bytes.
Re: reading config file one byte at a time
Posted by "Jeff Trawick (httpd)" <tr...@ibm.net>.
> Date: Thu, 15 Jun 2000 19:45:03 -0700
> From: "Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU>
>
> I haven't caught up with my mail yet, but found this while teaching
> an in-house class on Apache debugging tricks a couple hours ago.
>
> If you do an
>
> strace -f ./httpd -d /home/apache/serverroot >& outfile
>
> (or truss, depending on your system OS) you will see the following
>
> open("/home/fielding/ws/test/conf/httpd.conf", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=33482, ...}) = 0
> read(3, "#", 1) = 1
> read(3, "\n", 1) = 1
> read(3, "#", 1) = 1
> read(3, " ", 1) = 1
> read(3, "B", 1) = 1
> read(3, "a", 1) = 1
> read(3, "s", 1) = 1
> read(3, "e", 1) = 1
> read(3, "d", 1) = 1
> read(3, " ", 1) = 1
> ...
> ...
> ...
>
> Needless to say, that sucks. I figure it is a degenerate case of the
> new iol code or saferead or something like that. I'll check into it
> later tonight if I get a chance (laundry night).
>
> This is on Linux, though it probably isn't OS-specific.
>
> ....Roy
>
I posted enough fixes for the Unix buffering logic to get ap_fgets()
(and thus config file reading) working o.k. Brian Havard later made
some changes to Win32 to get ap_fgets() working with buffering (though
Greg S. didn't like it because it slowed down the non-buffered Win32
implementation).
As a follow-up to my patch (which Ryan and Brian didn't like for
not-well-specified reasons) I posted some additional questions
regarding file I/O stuff in general; these haven't generated any
discussion yet.
Manoj pointed out a way to get common code across platforms for
buffering.
I think the file I/O stuff could use a thorough cleanup in both the
design and implementation (e.g., doc says you can read 100 bytes *and*
get APR_EOF reported; this is not helpful to apps and is contrary to
existing APIs; luckily at least some of the code doesn't seem to do
this).
I'm relatively eager to clean this stuff up but more discussion is
needed on various issues.
Jeff
Re: reading config file one byte at a time
Posted by rb...@covalent.net.
> Needless to say, that sucks. I figure it is a degenerate case of the
> new iol code or saferead or something like that. I'll check into it
> later tonight if I get a chance (laundry night).
>
> This is on Linux, though it probably isn't OS-specific.
Yeah, it does suck. It's the new buffering logic. We have this in the
STATUS file as a showstopper. I think Jeff tried turning this on, but ran
into bugs with the buffering logic yesterday. Nobody really followered up
with his comments. It is most definately not OS-specific.
There are likely to be some real issues with the buffering logic on Unix,
because it was compiled but never tested.
Happy hacking.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------