apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject A bug in apr_file_gets() (win32/os2)?
Date Tue, 04 Mar 2003 19:01:37 GMT
Someone pointed out that we eat \r's in apr_file_gets() ... now if we
respected the BINARY flag to open that might not be "as much" of
a problem - but it's deeper than that...

We also don't reassemble \r\n pairs in apr_file_puts() either, which
means any file that goes while(apr_file_gets()) apr_file_puts(); will
be corrupted.  htpasswd.c is a good example of this.

Now one solution would be to respect the BINARY flag, but that
ignores the additional issue of APR_EOL_STR, and the Netware
implementation (Unix'es) that doesn't do anything like 'dropping'
\r's on the floor.  It keeps them.

If we define APR_EOL_STR, then our API's should be returning 
and assembling strings consistent with APR_EOL_STR, IMHO.
Any other opinions or should I go ahead and apply the attached
patch that doesn't do anything special with 'eliminating' \r's?

Bill

p.s. the code I believe could be affected today on Netware, and with
this patch on OS2/Win32 in the future...

mod_disk_cache.c lns 237, 260, 
(ln 537 is good since scan_script_headers 'does the right thing' w.r.t. \r's
according to util_script.c ln 473)

mod_cgi.c ln 246 (similar in mod_cgid though it might only apply to Unix.)

mod_negotation.c (??? haven't reviewed in it's entirety)

ssl_engine_pphrase.c ln 629 (ewww)

And a few others... I simply grepped for apr_file_gets() and didn't drill into
every '\n' that might be ignoring the possibility of '\r'.
Mime
View raw message