date:20050708


Joe Schaefer wrote:

Fresh roll of trunk (and backing off the stable release
plan for 2.06):

http://people.apache.org/~joes/libapreq2-2.06-dev-rc1.tar.gz

Please test and report back.


Joe,

the link on the page says 2.05-dev-RC1
I'll have some feedback shortly.

The underlying href is fine though.


--
END

What doesn't kill us can only make us stronger.
Nothing is impossible.

Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com

Re: Please test 2.06-dev-rc1


Philip M. Gollucci wrote:

Joe Schaefer wrote:


Fresh roll of trunk (and backing off the stable release
plan for 2.06):

http://people.apache.org/~joes/libapreq2-2.06-dev-rc1.tar.gz

Please test and report back.

The first thing thats killing me is the autotools versioning
like

aclocal-1.6

Well in FBSD for instantance its installed as aclocal16
(or in my case aclocal19)

same goes for automake and and autoconf.

Not neccessary a bug, but I had to symlink things around.
[I guess I could have specified arguments to ./buildconf]


--
END

What doesn't kill us can only make us stronger.
Nothing is impossible.

Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com

Re: [VOTE] mod_ftp for HTTP Server Project

2005-07-08 Thread Mladen Turk


Jim Jagielski wrote:


I therefore Call A Vote on whether we should support mod_ftp for
inclusion into the Incubator and if we should accept mod_ftp upon
graduation from the Incubator.




+1

Regards,
Mladen.

Re: [Patch 2.0] d2i_SSL_SESSION args for 0.9.7f-/0.9.7g/0.9.8

On Thu, Jul 07, 2005 at 06:51:04PM -0500, William Rowe wrote:
 Attached is a backport of rev 209530, which demanded a little
 bit of rework to make it functional.
 
 This resolves build issues which caused errors in 0.9.7f and
 prior on Win32 and build failures on Netware.  This patch
 correctly chooses the appropriate const-ness for 0.9.6, 0.9.7,
 or 0.9.8 OpenSSL.  It needs to be verified on Netware since
 my Win32 builds completely clean.

-1, this is barely readable, using a #define as previously or a typedef 
in ssl_toolkit_compat.h is much cleaner.

joe

Re: [vote] MODULE_MAGIC_COOKIE

2005-07-08 Thread Sander Striker


William A. Rowe, Jr. wrote:

At 01:33 PM 7/1/2005, William A. Rowe, Jr. wrote:


I have bumped the MODULE_MAGIC_COOKIE for 2.1.7.  This will be
bumped again upon 2.2 release to AP22.



-#define MODULE_MAGIC_COOKIE 0x41503230UL /* AP20 */
+#define MODULE_MAGIC_COOKIE 0x41503231UL /* AP21 */



The question remains, so please choose one;

  [ ] Revert the cookie to AP20 for httpd-2.1 and httpd-2.2
  [ ] Leave the cookie at AP21 and bump again to AP22 w/httpd-2.2
  [X] Get it over with already and bump now to AP22 for httpd-2.1


Sander

Re: svn commit: r209723 - /httpd/httpd/trunk/CHANGES

On Fri, Jul 08, 2005 at 09:35:58AM -, Paul Querna wrote:
Author: pquerna
Date: Fri Jul 8 02:35:56 2005
New Revision: 209723

URL: http://svn.apache.org/viewcvs?rev=209723view=rev
Log:
The request smuggling issue did get assigned CAN-2005-2088.

Ah, I was just about to commit a different change to clear this up.

CAN-2005-2088 only refers to the fix for the specific *request* handling
issue highlighted in the watchfire report. No CVE name has been
assigned for fix for response handling in the proxy since there is no
real security issue there in httpd. (nobody has demonstrated one,
anyway; it would probably require a separate CVE name)

The changes in 2.1.5 did not actually fix CAN-2005-2088, however. So we
could move that CHANGES entry from the 2.1.5 section to the 2.1.6
section to clarify this.

The security references should be removed from the proxy HTTP: ...
entry completely, I think, certainly the CVE reference must be.

joe

Modified:
httpd/httpd/trunk/CHANGES

Modified: httpd/httpd/trunk/CHANGES
URL:
http://svn.apache.org/viewcvs/httpd/httpd/trunk/CHANGES?rev=209723r1=209722r2=209723view=diff
==
--- httpd/httpd/trunk/CHANGES (original)
+++ httpd/httpd/trunk/CHANGES Fri Jul 8 02:35:56 2005
@@ -19,7 +19,7 @@
*) Fix htdbm password validation for records which included comments.
[Eric Covener covener gmail.com]

- *) SECURITY:
+ *) SECURITY: CAN-2005-2088
proxy HTTP: If a response contains both Transfer-Encoding and a
Content-Length, remove the Content-Length and don't reuse the
connection, stopping some HTTP Request smuggling attacks.
@@ -30,7 +30,7 @@

Changes with Apache 2.1.5

- *) SECURITY:
+ *) SECURITY: CAN-2005-2088
core: If a request contains both Transfer-Encoding and a Content-Length,
remove the Content-Length, stopping some HTTP Request smuggling attacks.
[Paul Querna]

Re: [VOTE] mod_ftp for HTTP Server Project

2005-07-08 Thread Geoffrey Young



Jim Jagielski wrote:
 Now that Covalent has released it's ERS 3.0 distribution, mod_ftp is now
 officially offered for donation/incubation/graduation to the ASF.

sounds like fun

 The entire code-base, including Perl test scripts for inclusion in 
 httpd-test,
 is available and ready for donation into the ASF svn repos.

if help, mentoring, or other foo is needed on the httpd-test front I'm more
than willing to donate whatever time or assistance is needed.

 I therefore Call A Vote on whether we should support mod_ftp for
 inclusion into the Incubator and if we should accept mod_ftp upon
 graduation from the Incubator.

+1

--Geoff

Re: [vote(s)] [Patch 1.3] Strict proxy C-L / T-E conformance

2005-07-08 Thread Jim Jagielski

William A. Rowe, Jr. wrote:
 
 I corrected the ap_strtol result tests, based on the fact that
 it's *our* strtol, and we know we will hiccup errno if we see
 out of range, or no digits at all, and end_ptr is guarenteed
 to be set.
 

We do not use our strtol on OS/2 or Win32. I'm not sure on what
their strtol implementation does.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
 Sith happens  -  Yoda

Re: [mod_python] Articles on module importing.

2005-07-08 Thread Gregory (Grisha) Trubetskoy



On Thu, 7 Jul 2005, Graham Dumpleton wrote:


 http://www.dscpl.com.au/articles/modpython-003.html


I think this is great. Thanks for taking the time to write this!

Now we need a plan for addressing all of those things.

I think it would be great if perhaps in the text of the article each issue 
had a link to a corresponding JIRA (_some_ do already, but more could be 
opened) and if the issue is resolved it was clearly noted (e.g. ISSUE 5).


Then we need to decide whether the issue should be fixed for 3.2 or tabled 
for later.


I'm going to send a comment to the list on one issue (starting from the 
top), but I'll do this in a separate thread, trying to keep an e-mail 
thread per issue.


Grisha

[importing] Disabling of AutoReload

2005-07-08 Thread Gregory (Grisha) Trubetskoy



I think that the issue of import_module not honoring the AutoReload and 
Debug directives (because it was originally only used internally and was 
used a level below the directives) is a fairly serious one and something 
should be done before 3.2.


So perhaps we rename import_module() to something else, and create a 
separate import_module which checks the directives, then calls the low 
level one?


Grisha

Re: Generated spool file okay to copy after parse?

2005-07-08 Thread Jeffrey Horner


Joe Schaefer wrote:
[...]

Maybe :-).  The internal behavior of the spool brigades is something
we need to work on from the httpd-side, since they have slightly
different needs.  I want to see our spool buckets become a bit
smarter: right now mod_apreq2 is creating multiple spool files
when it could (in principle) consolidate them into a single file.
The safest thing for you to do right now is to write copy the brigade
to a separate file.  You shouldn't peek inside the brigade to
look at the bucket types yet; ideally we'll provide another 
utility function to intelligently write the spool brigade to 
a file (here's my +1 for a patch to apreq_util.[ch] that adds an 
apreq_brigade_copy_to_file function).


I'm not sure I like the idea of spooling the files to a tmp file just to 
copy them to another tmp file, which will ultimately be copied to 
another file by the script writer. Imagine this cost with a 500Mb file.


My next idea is to create a hook to siphon off all the brigades for file 
params and write to the tmp files myself. This way, I'm using the 
libapreq api and not presuming what the internals do...


How's that sound?

--
Jeffrey Horner   Computer Systems Analyst School of Medicine
615-322-8606 Department of Biostatistics   Vanderbilt University

Re: [Patch 2.0] d2i_SSL_SESSION args for 0.9.7f-/0.9.7g/0.9.8

At 01:48 AM 7/8/2005, Joe Orton wrote:
On Thu, Jul 07, 2005 at 06:51:04PM -0500, William Rowe wrote:
 
 This resolves build issues which caused errors in 0.9.7f and
 prior on Win32 and build failures on Netware.  This patch
 correctly chooses the appropriate const-ness for 0.9.6, 0.9.7,
 or 0.9.8 OpenSSL.  It needs to be verified on Netware since
 my Win32 builds completely clean.

-1, this is barely readable, using a #define as previously or a typedef 
in ssl_toolkit_compat.h is much cleaner.

Then we need three of them, but do we want to simplify this with
the appropriate version tests to...

#define MODSSL_CONST_D2I_SSL_SESSION   const
#define MODSSL_CONST_D2I_X509  const
#define MODSSL_CONST_D2I_PrivateKeyconst

And simply use that as a modifier, so the reader can follow
that the type is an unsigned char * in the main code, without
going back to ssl_toolkit_compat.h?  Or us a full type, which
is less legible (requires the reader to know that D2I datum
are unsigned char *)?

Bill

Re: [Patch 2.0] d2i_SSL_SESSION args for 0.9.7f-/0.9.7g/0.9.8

On Fri, Jul 08, 2005 at 09:53:44AM -0500, William Rowe wrote:
 
 At 01:48 AM 7/8/2005, Joe Orton wrote:
 On Thu, Jul 07, 2005 at 06:51:04PM -0500, William Rowe wrote:
  
  This resolves build issues which caused errors in 0.9.7f and
  prior on Win32 and build failures on Netware.  This patch
  correctly chooses the appropriate const-ness for 0.9.6, 0.9.7,
  or 0.9.8 OpenSSL.  It needs to be verified on Netware since
  my Win32 builds completely clean.
 
 -1, this is barely readable, using a #define as previously or a typedef 
 in ssl_toolkit_compat.h is much cleaner.
 
 Ok, attached is a const-flag based solution buried back into
 ssl_toolkit_compat.h, that I believe is the most readable.
 
 Comments/Votes?  2.0.x patch attached; 2.1 committed.

+1 for 2.0.x if the below is changed to use (unsigned char *) rather 
than (UCHAR *) in the cast too.  Thanks for fixing this!

 --- ssl_scache_dbm.c  (revision 209795)
 +++ ssl_scache_dbm.c  (working copy)
 @@ -193,7 +193,7 @@
  apr_datum_t dbmkey;
  apr_datum_t dbmval;
  SSL_SESSION *sess = NULL;
 -UCHAR *ucpData;
 +MODSSL_D2I_SSL_SESSION_CONST unsigned char *ucpData;
  int nData;
  time_t expiry;
  time_t now;
 @@ -234,13 +234,14 @@
  
  /* parse resulting data */
  nData = dbmval.dsize-sizeof(time_t);
 -ucpData = (UCHAR *)malloc(nData);
 +ucpData = malloc(nData);
  if (ucpData == NULL) {
  apr_dbm_close(dbm);
  ssl_mutex_off(s);
  return NULL;
  }
 -memcpy(ucpData, (char *)dbmval.dptr+sizeof(time_t), nData);
 +/* Cast needed, ucpData may be const */
 +memcpy((UCHAR *)ucpData, (char *)dbmval.dptr+sizeof(time_t), nData);
  memcpy(expiry, dbmval.dptr, sizeof(time_t));
  
  apr_dbm_close(dbm);

Re: [PATCH] Allow for internal OpenSSL Session Cache

On Tue, Jul 05, 2005 at 01:32:54PM -0400, Jim Jagielski wrote:
 I've run into this with some broken browsers. Basically, they
 require a non-null SessionID in the SSL transaction. If, for whatever
 reason, we disable the external SSL Session Cache, these
 browsers reports errors when connecting to the SSL vhost.
 
 This adds a new argument to SSLSessionCache which says disable any
 external session cache, but use OpenSSL's internal one which makes
 OpenSSL send the SessionID parameter again.

Is the session cache in this mode bounded in memory use, i.e. does it
handle session expiry properly?  The memory leaks in the shm* caches
that got fixed a while back were caused by the internal session cache
which was never getting purged and just grew in size indefinitely.

But, anyway, it's very well known that MSIE barfs if you turn off the 
SSL session cache, that's why you don't do that.  The question is 
begged... why were you turning off the session cache?

This seems a bit like a shot-yourself-in-the-foot situation.  Adding 
*more* config options as a response to people setting config options 
incorrectly in the first place doesn't seem very sensible to me.

Regards,

joe

Re: [Patch 2.0] d2i_SSL_SESSION args for 0.9.7f-/0.9.7g/0.9.8

2005-07-08 Thread Brad Nicholes

+1 on the patch in general.  It seems to work for NetWare.  However, since we 
only build mod_ssl for 2.1/2.2 and only target openssl 0.9.8, I can't really 
comment on the 2.0 backport other than I expect it to work there as well.

Brad

 [EMAIL PROTECTED] Friday, July 08, 2005 9:00:00 AM 
On Fri, Jul 08, 2005 at 09:53:44AM -0500, William Rowe wrote:
 
 At 01:48 AM 7/8/2005, Joe Orton wrote:
 On Thu, Jul 07, 2005 at 06:51:04PM -0500, William Rowe wrote:
  
  This resolves build issues which caused errors in 0.9.7f and
  prior on Win32 and build failures on Netware.  This patch
  correctly chooses the appropriate const-ness for 0.9.6, 0.9.7,
  or 0.9.8 OpenSSL.  It needs to be verified on Netware since
  my Win32 builds completely clean.
 
 -1, this is barely readable, using a #define as previously or a typedef 
 in ssl_toolkit_compat.h is much cleaner.
 
 Ok, attached is a const-flag based solution buried back into
 ssl_toolkit_compat.h, that I believe is the most readable.
 
 Comments/Votes?  2.0.x patch attached; 2.1 committed.

+1 for 2.0.x if the below is changed to use (unsigned char *) rather 
than (UCHAR *) in the cast too.  Thanks for fixing this!

 --- ssl_scache_dbm.c  (revision 209795)
 +++ ssl_scache_dbm.c  (working copy)
 @@ -193,7 +193,7 @@
  apr_datum_t dbmkey;
  apr_datum_t dbmval;
  SSL_SESSION *sess = NULL;
 -UCHAR *ucpData;
 +MODSSL_D2I_SSL_SESSION_CONST unsigned char *ucpData;
  int nData;
  time_t expiry;
  time_t now;
 @@ -234,13 +234,14 @@
  
  /* parse resulting data */
  nData = dbmval.dsize-sizeof(time_t);
 -ucpData = (UCHAR *)malloc(nData);
 +ucpData = malloc(nData);
  if (ucpData == NULL) {
  apr_dbm_close(dbm);
  ssl_mutex_off(s);
  return NULL;
  }
 -memcpy(ucpData, (char *)dbmval.dptr+sizeof(time_t), nData);
 +/* Cast needed, ucpData may be const */
 +memcpy((UCHAR *)ucpData, (char *)dbmval.dptr+sizeof(time_t), nData);
  memcpy(expiry, dbmval.dptr, sizeof(time_t));
  
  apr_dbm_close(dbm);

Re: Generated spool file okay to copy after parse?

2005-07-08 Thread Jeffrey Horner


Joe Schaefer wrote:
[...]
Certainly doable, but I think it'd be overkill.  We deal with these 
exact same issues (by cheating and peeking at the spool bucket 
implementation) in the perl glue, so having a common C API makes the

most sense to me.



I don't claim expertise at understanding the Perl glue, but you might
have a bug on your hands for the Apache2::Params::upload_link()
function. If the brigade limit was set during parsing such that a file
upload brigade contained heap buckets and a spool bucket at the end,
then upload_link() looks like it may just copy the spool bucket,
ignoring the heap buckets.

Regardless, since libapreq already exposes the spool bucket file via the
api call apreq_brigade_spoolfile(), plus the fact the the Perl glue uses
it, I think it's a safe bet that the api will support some sort of
access to the tmp file created in the future.


--
Jeffrey Horner   Computer Systems Analyst School of Medicine
615-322-8606 Department of Biostatistics   Vanderbilt University

Re: [Patch 2.0] d2i_SSL_SESSION args for 0.9.7f-/0.9.7g/0.9.8

At 10:00 AM 7/8/2005, Joe Orton wrote:
 Comments/Votes?  2.0.x patch attached; 2.1 committed.

+1 for 2.0.x if the below is changed to use (unsigned char *) rather 
than (UCHAR *) in the cast too.  Thanks for fixing this!

I will switch these to (unsigned char *)... from (UCHAR *)

but need Netware Metrowerks compiler feedback, please!

Re: svn commit: r209823 - /httpd/httpd/trunk/modules/ssl/ssl_scache_dbm.c

2005-07-08 Thread Brad Nicholes

+1 netware

Brad

 [EMAIL PROTECTED] Friday, July 08, 2005 9:52:02 AM 
Author: wrowe
Date: Fri Jul  8 08:52:02 2005
New Revision: 209823

URL: http://svn.apache.org/viewcvs?rev=209823view=rev 
Log:

  No UCHAR, per Joe

Modified:
httpd/httpd/trunk/modules/ssl/ssl_scache_dbm.c

Modified: httpd/httpd/trunk/modules/ssl/ssl_scache_dbm.c
URL: 
http://svn.apache.org/viewcvs/httpd/httpd/trunk/modules/ssl/ssl_scache_dbm.c?rev=209823r1=209822r2=209823view=diff
 
==
--- httpd/httpd/trunk/modules/ssl/ssl_scache_dbm.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_scache_dbm.c Fri Jul  8 08:52:02 2005
@@ -244,7 +244,8 @@
 return NULL;
 }
 /* Cast needed, ucpData may be const */
-memcpy((UCHAR *)ucpData, (char *)dbmval.dptr+sizeof(time_t), nData);
+memcpy((unsigned char *)ucpData, 
+   (char *)dbmval.dptr + sizeof(time_t), nData);
 memcpy(expiry, dbmval.dptr, sizeof(time_t));
 
 apr_dbm_close(dbm);

Re: [vote] MODULE_MAGIC_COOKIE

2005-07-08 Thread Justin Erenkrantz

On Thu, Jul 07, 2005 at 10:51:09PM -0500, William A. Rowe, Jr. wrote:
   [ ] Revert the cookie to AP20 for httpd-2.1 and httpd-2.2
   [ ] Leave the cookie at AP21 and bump again to AP22 w/httpd-2.2
   [X] Get it over with already and bump now to AP22 for httpd-2.1

Re: [VOTE] mod_ftp for HTTP Server Project

2005-07-08 Thread Justin Erenkrantz

On Thu, Jul 07, 2005 at 02:26:13PM -0400, Jim Jagielski wrote:
 I therefore Call A Vote on whether we should support mod_ftp for
 inclusion into the Incubator and if we should accept mod_ftp upon
 graduation from the Incubator.

+1.  -- justin

Re: svn commit: r209854 - /httpd/httpd/trunk/CHANGES

Please don't remove that altogether.

The proper name of the entire class of vulnerabilities (of which
Splitting and Spoofing are a subset) is HTTP Response Splitting.

At 01:16 PM 7/8/2005, [EMAIL PROTECTED] wrote:
Author: jorton
Date: Fri Jul  8 11:16:49 2005
New Revision: 209854

URL: http://svn.apache.org/viewcvs?rev=209854view=rev
Log:
Don't talk about request smuggling in the response handling fix.

Modified:
httpd/httpd/trunk/CHANGES

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewcvs/httpd/httpd/trunk/CHANGES?rev=209854r1=209853r2=209854view=diff
==
--- httpd/httpd/trunk/CHANGES (original)
+++ httpd/httpd/trunk/CHANGES Fri Jul  8 11:16:49 2005
@@ -30,8 +30,7 @@
 
   *) proxy HTTP: If a response contains both Transfer-Encoding and a 
  Content-Length, remove the Content-Length and don't reuse the
- connection, stopping some HTTP Request smuggling attacks.
- [Jeff Trawick]
+ connection.  [Jeff Trawick]
 
   *) mod_cgid: Fix buffer overflow processing ScriptSock directive.
  [Steve Kemp steve steve.org.uk]
@@ -122,7 +121,7 @@
   
   *) mod_deflate: Merge the Vary header, isntead of Setting it. Fixes
  applications that send the Vary Header themselves, and also apply 
- mod_defalte as an output filter. [Paul Querna]
+ mod_deflate as an output filter. [Paul Querna]
 
   *) Change the default (when not present in the config file) setting
  for UseCanonicalName to Off.

Re: [VOTE] mod_ftp for HTTP Server Project

At 01:26 PM 7/7/2005, Jim Jagielski wrote:
I therefore Call A Vote on whether we should support mod_ftp for
inclusion into the Incubator and if we should accept mod_ftp upon
graduation from the Incubator.

++1

I see this more valuable to httpd as a case study in alternate
protocols than the ftp: scheme it offers.  Until we have several
modules, mod_snmp, mod_ftp, etc, we will never truly recognize
where we must divide connection from resource from request.

Some have asked if there is anything more to do.  Others asked
if it would support -x- (caching, content, whatever).

Resources are served as sub-requests of the 'connection' (login)
request.  So they can contain anything, be cached or not, etc.
The entire gamut of what you can serve from http: flows to ftp:

But certainly more can be done.  The request model in an httpd 2.2
or 2.4 version can become much cleaner, as we better divide the
components of httpd.

Bill

Re: Please test 2.06-dev-rc1


Philip M. Gollucci wrote:

Philip M. Gollucci wrote:


Joe Schaefer wrote:


Fresh roll of trunk (and backing off the stable release
plan for 2.06):

http://people.apache.org/~joes/libapreq2-2.06-dev-rc1.tar.gz

Please test and report back.

in

cd glue/perl

gmake test TEST_VERBOSE=1 TEST_FILES=t/apreq/request.t
==
# testing : basic upload length
# expected: 101000
# received: 101000
ok 13
dubious
Test returned status 0 (wstat 13, 0xd)
DIED. FAILED tests 14-18
Failed 5/18 tests, 72.22% okay
Failed Test   Stat Wstat Total Fail  Failed  List of Failed

in t/logs/error_log

Attempt to free temp prematurely: SV 0x8443e90.
[Fri Jul 08 14:40:29 2005] [error] [client 127.0.0.1] Attempt to free 
unreferenced scalar: SV 0x8443e90 at 
/usr/local/apps/dev/src/libapreq2-2.06-dev/glue/perl/t/response/TestApReq/request.pm 
line 117.


IF I add the -d flag in the Makefile to the PERL lines I get this

# received: 500 Connection reset by peer
not ok 14
# Failed test 14 in t/apreq/request.t at line 28 fail #7
# testing : basic upload length
# expected: 101000
# received: 0
not ok 15

# testing : disabled uploads
# expected: ok
# received: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
# htmlhead
# title500 Internal Server Error/title
# /headbody
# h1Internal Server Error/h1
# pThe server encountered an internal error or
# misconfiguration and was unable to complete
# your request./p
# pPlease contact the server administrator,
#  [EMAIL PROTECTED] and inform them of the time the error occurred,
# and anything you might have done that may have
# caused the error./p
# pMore information about this error may be available
# in the server error log./p
# /body/html
not ok 18
# Failed test 18 in t/apreq/request.t at line 54




This is FBSD 5.4, mod_perl 2.0.2-dev, perl 5.8.7 no ithreads, httpd-2.1.7

I have a feeling its a 2.1.x issue, I'll retry with 2.0.54 shortly.




--
END

What doesn't kill us can only make us stronger.
Nothing is impossible.

Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com

Re: Please test 2.06-dev-rc1


Philip M. Gollucci wrote:

Philip M. Gollucci wrote:


Joe Schaefer wrote:


Fresh roll of trunk (and backing off the stable release
plan for 2.06):

http://people.apache.org/~joes/libapreq2-2.06-dev-rc1.tar.gz

Please test and report back.


gmake docs_install
[lots of docxygen errors]
snipped

cp -a docs /usr/local/apps/httpd-2.1.7/share/libapreq2
cp: illegal option -- a
usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
   cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN directory
gmake: *** [docs_install] Error 64

CP on FreeBSD doesn't have the -a option.
I read a linux man page (-a is equivalent to -dpR). FreeBSD doesn't have 
-d or -p either.


I believe you want just
cp -R or you'll have to use the bsd install script to be portable.

--
END

What doesn't kill us can only make us stronger.
Nothing is impossible.

Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com

[RESULT] MODULE_MAGIC_COOKIE

At 03:02 PM 7/8/2005, many had written:
  [ ] Revert the cookie to AP20 for httpd-2.1 and httpd-2.2
  [ ] Leave the cookie at AP21 and bump again to AP22 w/httpd-2.2
  [x] Get it over with already and bump now to AP22 for httpd-2.1

This is as unanimous as I've ever seen.  I'm bumping now.

Dev's, you will need to rebuild 3rd party modules or they won't
load after you have cvs up'ped.

Re: [vote] MODULE_MAGIC_COOKIE

2005-07-08 Thread Graham Leggett


William A. Rowe, Jr. wrote:


  [ ] Revert the cookie to AP20 for httpd-2.1 and httpd-2.2
  [ ] Leave the cookie at AP21 and bump again to AP22 w/httpd-2.2
  [X] Get it over with already and bump now to AP22 for httpd-2.1



Regards,
Graham
--

Re: [VOTE] mod_ftp for HTTP Server Project

2005-07-08 Thread Graham Leggett


Jim Jagielski wrote:


I therefore Call A Vote on whether we should support mod_ftp for
inclusion into the Incubator and if we should accept mod_ftp upon
graduation from the Incubator.


+1

Regards,
Graham
--

Re: [VOTE] mod_ftp for HTTP Server Project

2005-07-08 Thread Jeff Trawick

On 7/7/05, Jim Jagielski [EMAIL PROTECTED] wrote:

 I therefore Call A Vote on whether we should support mod_ftp for
 inclusion into the Incubator and if we should accept mod_ftp upon
 graduation from the Incubator.

+1 (not that you need any more votes)

FTP can be crufty, but ftp clients are everywhere, and for that reason
it is useful to provide ftp as a way to get at data without a hassle,
particularly on random boxes where you don't want to worry if client
software for more modern protocols is already installed/configured.

[vote(s)] [Patch 1.3] Strict proxy C-L / T-E conformance

[22 hours - ping]

Votes please?  2/3 of our users use 1.3, do you?

Jim reminded me we don't ap_strtol everywhere, so the NULL check
I guess remains a good idea, as would a (len_end == content_length)
test which I will add before committing.

Bill


At 08:35 AM 7/7/2005, Roy T. Fielding wrote:

 It looks like a band-aid to me -- how does this module know that
 the server doesn't support other transfer encodings?  Wouldn't
 it be better to register a set of transfer encoding filters and
 then error if none matches?  Oh, never mind, this is for 1.3. +0.

Actually for 1.3, this patch is doing a couple things for the
proxy response from the origin server to the client;

*) It enforces 'chunked' as the only legitimate T-E

*) It unsets the C-L header if the T-E header is present

*) To avoid 'suspect' responses, it won't cache any response
   with both a T-E and C-L header  (If we used keep alive
   backend connections, it would also want to close that.)

I corrected the ap_strtol result tests, based on the fact that
it's *our* strtol, and we know we will hiccup errno if we see
out of range, or no digits at all, and end_ptr is guarenteed
to be set.

Remember in 1.3 mod_proxy won't pass up a chunked request body
so that whole scenario is ignored for now.  If the client (or
previous proxy hop) passes T-E, the request is rejected.

I believe this patch handles all the scenarios in 1.3, combined
with Jeff's request TE+CL patch.  Further comment or specific
votes to the behaviors above are welcome.  Would like to commit
tomorrow to roll a release candidate.

I am still waiting for the answer to the question; does mod_gzip
or any other 3p module we know of actually introduce an alternate
Transfer-Encoding to 1.3?

Bill Index: src/modules/proxy/proxy_http.c
===
--- src/modules/proxy/proxy_http.c  (revision 209415)
+++ src/modules/proxy/proxy_http.c  (working copy)
@@ -121,7 +121,7 @@
 char portstr[32];
 pool *p = r-pool;
 int destport = 0;
-int chunked = 0;
+const char *chunked = NULL;
 char *destportstr = NULL;
 const char *urlptr = NULL;
 const char *datestr, *urlstr;
@@ -338,7 +338,12 @@
 ap_table_mergen(req_hdrs, X-Forwarded-Server, 
r-server-server_hostname);
 } 
 
-/* we don't yet support keepalives - but we will soon, I promise! */
+/* we don't yet support keepalives - but we will soon, I promise! 
+ * XXX: This introduces various HTTP Request vulnerabilies if not
+ * properly implemented.  Before changing this .. be certain to
+ * add a hard-close of the connection if the T-E and C-L headers
+ * are both present, or the C-L header is malformed.
+ */
 ap_table_set(req_hdrs, Connection, close);
 
 reqhdrs_arr = ap_table_elts(req_hdrs);
@@ -475,25 +480,40 @@
 }
 
 /* is this content chunked? */
-chunked = ap_find_last_token(r-pool,
- ap_table_get(resp_hdrs, 
Transfer-Encoding),
- chunked);
+chunked = ap_table_get(resp_hdrs, Transfer-Encoding);
+if (chunked  (strcasecmp(chunked, chunked) != 0)) {
+ap_kill_timeout(r);
+return ap_proxyerror(r, HTTP_BAD_GATEWAY, ap_pstrcat(r-pool,
+ Unsupported Transfer-Encoding , chunked,
+  from remote server, NULL));
+}
 
 /* strip hop-by-hop headers defined by Connection and RFC2616 */
 ap_proxy_clear_connection(p, resp_hdrs);
 
 content_length = ap_table_get(resp_hdrs, Content-Length);
 if (content_length != NULL) {
-c-len = ap_strtol(content_length, NULL, 10);
+if (chunked) {
+/* XXX: We would unset keep-alive here, to the proxy
+ * origin server, for safety's sake but we aren't using
+ * keep-alives (we force Connection: close  above)
+ */
+nocache = 1;/* do not cache this suspect file */
+ap_table_unset(resp_hdrs, Content-Length);
+}
+else {
+char *len_end;
+errno = 0;
+c-len = ap_strtol(content_length, len_end, 10);
 
-   if (c-len  0) {
-   ap_kill_timeout(r);
-   return ap_proxyerror(r, HTTP_BAD_GATEWAY, ap_pstrcat(r-pool,
-Invalid Content-Length from remote 
server,
-  NULL));
+if (errno || *len_end || (c-len  0)) {
+ap_kill_timeout(r);
+return ap_proxyerror(r, HTTP_BAD_GATEWAY, 
+ Invalid Content-Length from remote
+  server);
+}
}
 }
-
 }
 else {
 /* an http/0.9 response */
@@ -612,7 +632,7 @@
  *

1.3 and 2.0 releases?