Re: Patch for query string customization?

[Brett E.]

Sorry for the confusion. I meant is it possible to use a #define macro 
for the query string delimiter. Ie, everywhere we use '?' in the code, 
use say QUERY_STRING_DELIM. For example:

modules/mappers/mod_rewrite.c:

q = strchr(r->filename, '?');

to

q = strchr(r->filename, QUERY_STRING_DELIM);

..everywhere in the code.

Thanks,

Brett

André Malo wrote:
* "Brett E." <[EMAIL PROTECTED]> wrote:


Would the powers that be accept a patch which would define the query 
string as a macro, possibly specified in configure and with sane 
defaults of course?


Sorry, I don't understand your idea. Can you explain it more? Thanks.

nd

Re: cvs commit: httpd-2.0 NOTICE LICENSE buildconf

[Justin Erenkrantz]

--On Friday, February 6, 2004 10:55 PM +0100 André Malo <[EMAIL PROTECTED]> 
wrote:

Doh! I'll fix it :-)

Thanks, nd
Thank *you* for taking this on!  ;-)  -- justin

Re: [PATCH] More sensible behavior(?) when zero-length pid file is found

[Justin Erenkrantz]

--On Thursday, February 5, 2004 2:01 PM +0100 Martin Kraemer 
<[EMAIL PROTECTED]> wrote:

When, with httpd-2.1, the pid file exists but has a zero size, then
httpd refuses to start.
The attached patch changes this behavior and removes the empty pid file
(but only if it exists AND is empty) and logs a message:
  (17)File exists: Zero-length PID file logs/httpd.pid ignored.
+1.  -- justin

Re: FileSystem v.s. Other Resources [was configurable Location?]

[gregames]

Joshua Slive wrote:
I do, however, agree that doing a directory-walk on virtual resources is
not nice.  But my opinion is that "virtualness" is a property of the
resource, and hence should be designated when selecting the resource.
That is why I suggested changing SetHandler rather than .


And perhaps I'm going way off in left field here, but why should this be
user-configurable at all?  Shouldn't the (for example) server-status
handler know itself that it is a virtual handler, and therefore indicate
that the directory-walk should be skipped?
I like it!  assuming we tweak it to be the module's responsibility to declare 
this property, vs. strictly the handler's (too late).

Greg

Re: FileSystem v.s. Other Resources [was configurable Location?]

[Greg Ames]

Greg Marr wrote:

I'm only changing  ...  is unaffected.


Well, that's not entirely true.  The  is affected indirectly, 
because it no longer applies.  The behavior currently is: it applies to 
everything it matches.  This would change it to: it applies to 
everything it matches unless it also matches a , in which case 
it doesn't apply.
OK, got it.  Thanks for the clear explanation.

This could possibly be handled by checking for overlaps between  and 
 at config time, especially if they are sorted in least-to-most 
specific order as wrowe suggests.

But my current favorite idea is Joshua's suggestion for the module to declare 
that the content is virtual, pure and simple.  In that case, any such overlaps 
are an admin screwup IMO.  GET /server-status/index.html doesn't make any sense 
to me even if such a directory exists.

Greg

Re: [PATCH] configurable Location block speed up

[Greg Ames]

Glenn wrote:
On Fri, Feb 06, 2004 at 10:37:51AM -0500, [EMAIL PROTECTED] wrote:

but Joshua has excellent points about "virtualness" being a property of the 
handler.  Yes, the server-status handler should know that it is virtual, 
but the handler hook is too late to skip the directory walk.  But the 
mod_status maintainers (i.e. us) know that mod_status is virtual, so maybe 
it could tell the core earlier somehow.  An earlier hook?  preferably 
something at config time since the virtualness doesn't ever change?


That got me thinking about a "handler capabilities" set of flags,
say, r->handler_attr, which is initialized to zeroes for each request.
The first single bit capability would be for, say,
HANDLER_ATTR_VIRTUAL_PATH (as opposed to filesystem-backed).
something like that.  I don't know if there are other uses for handler 
capabilities so it might be overkill at the moment.

In processing directives, SetHandler code could modify r->handler_attr
a nit - I think we would want to hide this type of info in something private to 
the core, like the core_request_config.

so that mod_status could set HANDLER_ATTR_VIRTUAL_PATH, after which
 and  would be skipped.  Hopefully it could be worked
out that  and  would be handled up until the point
where the request became virtual (/directory/path/then/virtual_path)
I'm still thinking of an all-or-nothing approach, i.e. it's in the filesystem or 
it's not, at least at first.  That's a pretty big change - look at the comments 
I'm getting and the cases I missed.

When it comes time to run the handler hook, modules could check this
flag in the same way that they check r->handler and r->content_type
to see if they should go ahead or DECLINE.  Alternatively, the 'module'
structure could be expanded to included a capabilities set and only
modules that flagged a capability would be given a chance to handle
the request.  Since the default handler only handles filesystem-backed
requests, it and other filesystem-backed modules would never see the
request.
  e.g. if (!(r->handler_attr & HANDLER_ATTR_VIRTUAL_PATH)
   || (foo_module->capabilities & HANDLER_ATTR_VIRTUAL_PATH))
Cheers,
Glenn

f

Re: [PATCH] RE: mod_ssl not sending Alert upon close ?

[Joe Orton]

On Fri, Feb 06, 2004 at 01:30:00PM -0800, Mathihalli, Madhusudan wrote:
> IOW, the following patch works.
> 
> Question: Is there any other hook / pool-cleanup thing that I can hook the 
> ssl_filter_io_shutdown() logic into ?

No, that can't be right either, it would close the connection after each
request.  I came to the same conclusion as you: this needs a new hook
which is run before the lingering close.

Could call it {close,finish,post}_connection or something like that: it
could be run from ap_process_connection.

joe

Re: cvs commit: httpd-2.0 NOTICE LICENSE buildconf

[André Malo]

* Justin Erenkrantz <[EMAIL PROTECTED]> wrote:

> --On Friday, February 6, 2004 9:48 PM + [EMAIL PROTECTED] wrote:
> 
> > nd  2004/02/06 13:48:40
> >
> >   Modified:.LICENSE buildconf
> >   Added:   .NOTICE
> >   Log:
> >   begin relicensing httpd-2.1 to Apache License, Version 2.0
> >
> >   Revision  ChangesPath
> >   1.10  +12 -56httpd-2.0/LICENSE
> 
> If I understand  correctly, 
> isn't LICENSE supposed to be the *full* license not the boilerplate?
> 
> Or, am I missing something?  -- justin

Doh! I'll fix it :-)

Thanks, nd

Re: cvs commit: httpd-2.0 NOTICE LICENSE buildconf

[Justin Erenkrantz]

--On Friday, February 6, 2004 9:48 PM + [EMAIL PROTECTED] wrote:

nd  2004/02/06 13:48:40

  Modified:.LICENSE buildconf
  Added:   .NOTICE
  Log:
  begin relicensing httpd-2.1 to Apache License, Version 2.0
  Revision  ChangesPath
  1.10  +12 -56httpd-2.0/LICENSE
If I understand  correctly, 
isn't LICENSE supposed to be the *full* license not the boilerplate?

Or, am I missing something?  -- justin

[PATCH] RE: mod_ssl not sending Alert upon close ?

[Mathihalli, Madhusudan]

IOW, the following patch works.

Question: Is there any other hook / pool-cleanup thing that I can hook the 
ssl_filter_io_shutdown() logic into ?

-Madhu

Index: mod_ssl.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/mod_ssl.c,v
retrieving revision 1.92
diff -u -r1.92 mod_ssl.c
--- mod_ssl.c   1 Jan 2004 13:26:21 -   1.92
+++ mod_ssl.c   6 Feb 2004 21:26:59 -
@@ -495,6 +495,50 @@
 }
 }
 
+static int ssl_hook_logger(request_rec *r)
+{
+const char *type = "";
+int shutdown_type;
+conn_rec *c = r->connection;
+SSLConnRec *sslconn = myConnConfig(c);
+SSL *ssl = sslconn->ssl;
+
+
+if (!ssl) {
+return OK;
+}
+
+switch (sslconn->shutdown_type) {
+  case SSL_SHUTDOWN_TYPE_UNCLEAN:
+/* perform no close notify handshake at all
+   (violates the SSL/TLS standard!) */
+shutdown_type = SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN;
+type = "unclean";
+break;
+  case SSL_SHUTDOWN_TYPE_ACCURATE:
+/* send close notify and wait for clients close notify
+   (standard compliant, but usually causes connection hangs) */
+shutdown_type = 0;
+type = "accurate";
+break;
+  default:
+/*
+ * case SSL_SHUTDOWN_TYPE_UNSET:
+ * case SSL_SHUTDOWN_TYPE_STANDARD:
+ */
+/* send close notify, but don't wait for clients close notify
+   (standard compliant and safe, so it's the DEFAULT!) */
+shutdown_type = SSL_RECEIVED_SHUTDOWN;
+type = "standard";
+break;
+}
+
+SSL_set_shutdown(ssl, shutdown_type);
+SSL_smart_shutdown(ssl);
+
+return OK;
+}
+
 /*
  *  the module registration phase
  */
@@ -516,6 +560,7 @@
 ap_hook_auth_checker  (ssl_hook_Auth,  NULL,NULL, APR_HOOK_MIDDLE);
 ap_hook_post_read_request(ssl_hook_ReadReq,NULL,NULL, APR_HOOK_MIDDLE);
 ap_hook_insert_filter (ssl_hook_Insert_Filter, NULL,NULL, APR_HOOK_MIDDLE);
+ap_hook_log_transaction(ssl_hook_logger,   NULL,NULL, APR_HOOK_MIDDLE);
 /*ap_hook_handler   (ssl_hook_Upgrade,   NULL,NULL, APR_HOOK_MIDDLE); */
 
 ssl_var_register();

-Original Message-
From: Mathihalli, Madhusudan 
Sent: Friday, February 06, 2004 7:57 AM
To: [EMAIL PROTECTED]
Subject: RE: mod_ssl not sending Alert upon close ?


Nope.. It didn't work that way.

The only way I've been able to get the Alert message on the client is by using the 
log_transaction hook to do the SSL_shutdown() - it's a ugly hack.

The more I think about it, I feel there's a need for something like pre-close hook OR 
have the lingering_close invoke the filter code for _CONNECTION_TYPE filters.

-Madhu



From: Joe Orton [mailto:[EMAIL PROTECTED]
Sent: Fri 2/6/2004 7:03 AM
To: [EMAIL PROTECTED]
Subject: Re: mod_ssl not sending Alert upon close ?


On Thu, Feb 05, 2004 at 02:03:29PM -0800, Mathihalli, Madhusudan wrote:
> Okay. here's what I think is happening : (Client => C Server -> S)

You're right, the alert is never getting sent!

> C  -> S : initiates connection
> C <-> S : handshake
> S  -> C : server sends application data
> S  -> C : server tries to read from the socket
>   -> finds nothing (0 bytes returned)
>   -> assumes transaction is completed, and starts cleanup process
>   -> closes the connection first
>   -> frees the pool, which invokes ssl_io_filter_cleanup() and inturn 
> ssl_io_filter_shutdown()
>   -> ssl_io_filter_shutdown() tries to send 'Close notify'
>  OOPS ! The connection has already been terminated

Yes - it's too late to rely on pool cleanups to send the alert: I think
the right place to do this is when the output filter gets the EOS
bucket: the patch below fixes for my tests, can you test against MSIE?

I'm not convinced about the ordering of the flush/shutdown...

--- modules/ssl/ssl_engine_io.c 23 Jan 2004 16:50:24 -  1.114
+++ modules/ssl/ssl_engine_io.c 6 Feb 2004 14:55:16 -
@@ -1404,6 +1404,11 @@
  * These types do not require translation by OpenSSL. 
  */
 if (APR_BUCKET_IS_EOS(bucket) || APR_BUCKET_IS_FLUSH(bucket)) {
+if (APR_BUCKET_IS_EOS(bucket)) {
+status = ssl_filter_io_shutdown(filter_ctx, f->c, 0);
+if (status) break;
+}
+
 if (bio_filter_out_flush(filter_ctx->pbioWrite) < 0) {
 status = outctx->rc;
 break;

Re: frustrating build experience *nix/windows

[William A. Rowe, Jr.]

If I grok what you are asking

 it would be nice if win32, too, would support VPATH builds with a --srcdir
like argument - and throw it's generated files in another directory tree.

Did I get the point?  This seems doable.

Bill

At 12:44 PM 2/6/2004, you wrote:
>William A. Rowe, Jr. wrote:
>
>>At 09:44 AM 2/6/2004, Aryeh Katz wrote:
>>
>>>In the 1.3 environment I was able to use the --shadow configure option to use the 
>>>same source tree for multiple os's. This was quite valuable, as one source code 
>>>change was needed for all platforms.
>>>However, the --shadow option is gone in 2.0. 
>>
>>
>>
>>>That's why there are two source packages, windows and UNIX.
>>
>>Actually that's not the reason.  The two reasons are:
>>1. line endings; msvc and msdev studio hate several files with unix line endings
>>   and either fail all together (nmake makefile) or produce erroneous results
>>   (emitted diagnostic line numbers from .c source files etc.)  The win32 package
>>   uses srclib/apr/build/lineends.pl to mop text files from one to the other form.
>>   Unless you are using a linux toolchain, or working on a volume that supports
>>   two views of the same file (e.g. Cygwin 'DOS' mounted unix volumes) this
>>   issue seems that it would continue to plague you.
>This might be the issue *nix to windows. I was having trouble the other direction. 
>After my windows builds my *nix builds were toast.
>>2. build files; this shouldn't be a hassle for you, it simply includes generated
>>   win32 exported makefiles and makefile dependencies from .pdb projects,along 
>> with the awk result .rc version files.  These aren't present in the
>>   Unix build, and are honestly not required to build the project if you use
>>   Visual Studio later than version 5.
>Actually, this was exactly my problem.
>apr.h, apu.h and a whole bunch of other files were generated by windows (and at least 
>I couldn't get it to clean up). Once those header files get included by the *nix 
>packages (despite the fact they have working apr.h etc in their own tree), the 
>sources won't compile.
>-- 
>Aryeh Katz
>SecureD Services
>http://www.secured-services.com/
>410 653 0700 x 2

Re: Patch for query string customization?

[André Malo]

* "Brett E." <[EMAIL PROTECTED]> wrote:

> Would the powers that be accept a patch which would define the query 
> string as a macro, possibly specified in configure and with sane 
> defaults of course?

Sorry, I don't understand your idea. Can you explain it more? Thanks.

nd

Re: [PATCH] configurable Location block speed up

[gregames]

Ben Laurie wrote:
[EMAIL PROTECTED] wrote:

[EMAIL PROTECTED] wrote:

or Joshua's "virtual" keyword on , which I like better the 
more I think about it.


ooops... s/Joshua/André/

but Joshua has excellent points about "virtualness" being a property 
of the handler.  Yes, the server-status handler should know that it is 
virtual, but the handler hook is too late to skip the directory walk.  
But the mod_status maintainers (i.e. us) know that mod_status is 
virtual, so maybe it could tell the core earlier somehow.  An earlier 
hook?  preferably something at config time since the virtualness 
doesn't ever change?


Isn't this going to be horribly messy? The current system says "oi, you 
- here's a URL, do you handle it?" whereas you'd need to have "oi, you, 
here's a pattern that might match a URL you handle, does it?".
it should be clean.  I'm thinking the module somehow communicates to the core 
that all its URLs are virtual, i.e., they don't map to the filesystem no way no 
how not ever.  Then we still need the


   SetHandler status_handler# or whatever it is

config/processing to take care of the pattern matching of the URLs, just like 
today.  If both of those things line up, then we can skip the directory walk.

btw, neither of the patches I posted do the communicating the virtualness to the 
core bit.  I just realized what Joshua was saying this morning.  The first patch 
assumes virtualness when it sees the config above, the second patch adds it as 
new config.  Having it communicated by the module is a much better idea.

Greg

Re: [PATCH] configurable Location block speed up

[Ben Laurie]

[EMAIL PROTECTED] wrote:

[EMAIL PROTECTED] wrote:

or Joshua's "virtual" keyword on , which I like better the 
more I think about it.


ooops... s/Joshua/André/

but Joshua has excellent points about "virtualness" being a property of 
the handler.  Yes, the server-status handler should know that it is 
virtual, but the handler hook is too late to skip the directory walk.  
But the mod_status maintainers (i.e. us) know that mod_status is 
virtual, so maybe it could tell the core earlier somehow.  An earlier 
hook?  preferably something at config time since the virtualness doesn't 
ever change?
Isn't this going to be horribly messy? The current system says "oi, you 
- here's a URL, do you handle it?" whereas you'd need to have "oi, you, 
here's a pattern that might match a URL you handle, does it?".

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: frustrating build experience *nix/windows

[Aryeh Katz]

William A. Rowe, Jr. wrote:

At 09:44 AM 2/6/2004, Aryeh Katz wrote:

In the 1.3 environment I was able to use the --shadow configure option to use the same source tree for multiple os's. This was quite valuable, as one source code change was needed for all platforms.
However, the --shadow option is gone in 2.0. 





That's why there are two source packages, windows and UNIX.


Actually that's not the reason.  The two reasons are:

1. line endings; msvc and msdev studio hate several files with unix line endings
   and either fail all together (nmake makefile) or produce erroneous results
   (emitted diagnostic line numbers from .c source files etc.)  The win32 package
   uses srclib/apr/build/lineends.pl to mop text files from one to the other form.
   Unless you are using a linux toolchain, or working on a volume that supports
   two views of the same file (e.g. Cygwin 'DOS' mounted unix volumes) this
   issue seems that it would continue to plague you.
This might be the issue *nix to windows. I was having trouble the other 
direction. After my windows builds my *nix builds were toast.
2. build files; this shouldn't be a hassle for you, it simply includes generated
   win32 exported makefiles and makefile dependencies from .pdb projects, 
   along with the awk result .rc version files.  These aren't present in the
   Unix build, and are honestly not required to build the project if you use
   Visual Studio later than version 5.


Actually, this was exactly my problem.
apr.h, apu.h and a whole bunch of other files were generated by windows 
(and at least I couldn't get it to clean up). Once those header files 
get included by the *nix packages (despite the fact they have working 
apr.h etc in their own tree), the sources won't compile.
--
Aryeh Katz
SecureD Services
http://www.secured-services.com/
410 653 0700 x 2

Patch for query string customization?

[Brett E.]

Would the powers that be accept a patch which would define the query 
string as a macro, possibly specified in configure and with sane 
defaults of course?



Thanks,

Brett

Re: [PATCH] configurable Location block speed up

[Glenn]

On Fri, Feb 06, 2004 at 10:37:51AM -0500, [EMAIL PROTECTED] wrote:
> but Joshua has excellent points about "virtualness" being a property of the 
> handler.  Yes, the server-status handler should know that it is virtual, 
> but the handler hook is too late to skip the directory walk.  But the 
> mod_status maintainers (i.e. us) know that mod_status is virtual, so maybe 
> it could tell the core earlier somehow.  An earlier hook?  preferably 
> something at config time since the virtualness doesn't ever change?

That got me thinking about a "handler capabilities" set of flags,
say, r->handler_attr, which is initialized to zeroes for each request.
The first single bit capability would be for, say,
HANDLER_ATTR_VIRTUAL_PATH (as opposed to filesystem-backed).

In processing directives, SetHandler code could modify r->handler_attr
so that mod_status could set HANDLER_ATTR_VIRTUAL_PATH, after which
 and  would be skipped.  Hopefully it could be worked
out that  and  would be handled up until the point
where the request became virtual (/directory/path/then/virtual_path)

When it comes time to run the handler hook, modules could check this
flag in the same way that they check r->handler and r->content_type
to see if they should go ahead or DECLINE.  Alternatively, the 'module'
structure could be expanded to included a capabilities set and only
modules that flagged a capability would be given a chance to handle
the request.  Since the default handler only handles filesystem-backed
requests, it and other filesystem-backed modules would never see the
request.
  e.g. if (!(r->handler_attr & HANDLER_ATTR_VIRTUAL_PATH)
   || (foo_module->capabilities & HANDLER_ATTR_VIRTUAL_PATH))

Cheers,
Glenn

Re: frustrating build experience *nix/windows

[William A. Rowe, Jr.]

At 09:44 AM 2/6/2004, Aryeh Katz wrote:
>In the 1.3 environment I was able to use the --shadow configure option to use the 
>same source tree for multiple os's. This was quite valuable, as one source code 
>change was needed for all platforms.
>However, the --shadow option is gone in 2.0. 



>That's why there are two source packages, windows and UNIX.

Actually that's not the reason.  The two reasons are:

1. line endings; msvc and msdev studio hate several files with unix line endings
   and either fail all together (nmake makefile) or produce erroneous results
   (emitted diagnostic line numbers from .c source files etc.)  The win32 package
   uses srclib/apr/build/lineends.pl to mop text files from one to the other form.
   Unless you are using a linux toolchain, or working on a volume that supports
   two views of the same file (e.g. Cygwin 'DOS' mounted unix volumes) this
   issue seems that it would continue to plague you.

2. build files; this shouldn't be a hassle for you, it simply includes generated
   win32 exported makefiles and makefile dependencies from .pdb projects, 
   along with the awk result .rc version files.  These aren't present in the
   Unix build, and are honestly not required to build the project if you use
   Visual Studio later than version 5.

>Can someone tell me why the --shadow option was removed?

Not I - other than we ditched our over-abused configure script in favor of
autoconf's inherent features.  As you suggest, --srcdir does the same thing.

Bill  

Re: FileSystem v.s. Other Resources [was configurable Location?]

[William A. Rowe, Jr.]

At 09:47 AM 2/6/2004, [EMAIL PROTECTED] wrote:
>William A. Rowe, Jr. wrote:
>>At 12:17 PM 2/5/2004, Joshua Slive wrote:
>>
I do, however, agree that doing a directory-walk on virtual resources is
not nice.  But my opinion is that "virtualness" is a property of the
resource, and hence should be designated when selecting the resource.
That is why I suggested changing SetHandler rather than .
>>>
>>>And perhaps I'm going way off in left field here, but why should this be
>>>user-configurable at all?  Shouldn't the (for example) server-status
>>>handler know itself that it is a virtual handler, and therefore indicate
>>>that the directory-walk should be skipped?
>>
>>For example, yes.  But on the other hand, what prevents someone from
>>removing the server-status handler in the fixups phase and tricking us into
>>serving a file.
>
>sounds like we're getting into defense mechanisms against hypothetical malicious 
>modules...  a loosing battle IMO

Malice?  Nah, defending against badly written or inherently insecure modules.
But much more to the discussion at hand...

...will administrators grok when  is a safe bet?  Will
it proliferate in example configurations in the wild, in unsafe ways?  I think
we can all presume it will.  Look at our frustrations with users that have
essentially open proxy configs, which they set up by following examples
that proliferate out there. 

Just playing defense here.

Bill

RE: mod_ssl not sending Alert upon close ?

[Mathihalli, Madhusudan]

Nope.. It didn't work that way.
 
The only way I've been able to get the Alert message on the client is by using the 
log_transaction hook to do the SSL_shutdown() - it's a ugly hack.
 
The more I think about it, I feel there's a need for something like pre-close hook OR 
have the lingering_close invoke the filter code for _CONNECTION_TYPE filters.
 
-Madhu



From: Joe Orton [mailto:[EMAIL PROTECTED]
Sent: Fri 2/6/2004 7:03 AM
To: [EMAIL PROTECTED]
Subject: Re: mod_ssl not sending Alert upon close ?



On Thu, Feb 05, 2004 at 02:03:29PM -0800, Mathihalli, Madhusudan wrote:
> Okay. here's what I think is happening : (Client => C Server -> S)

You're right, the alert is never getting sent!

> C  -> S : initiates connection
> C <-> S : handshake
> S  -> C : server sends application data
> S  -> C : server tries to read from the socket
>   -> finds nothing (0 bytes returned)
>   -> assumes transaction is completed, and starts cleanup process
>   -> closes the connection first
>   -> frees the pool, which invokes ssl_io_filter_cleanup() and inturn 
> ssl_io_filter_shutdown()
>   -> ssl_io_filter_shutdown() tries to send 'Close notify'
>  OOPS ! The connection has already been terminated

Yes - it's too late to rely on pool cleanups to send the alert: I think
the right place to do this is when the output filter gets the EOS
bucket: the patch below fixes for my tests, can you test against MSIE?

I'm not convinced about the ordering of the flush/shutdown...

--- modules/ssl/ssl_engine_io.c 23 Jan 2004 16:50:24 -  1.114
+++ modules/ssl/ssl_engine_io.c 6 Feb 2004 14:55:16 -
@@ -1404,6 +1404,11 @@
  * These types do not require translation by OpenSSL. 
  */
 if (APR_BUCKET_IS_EOS(bucket) || APR_BUCKET_IS_FLUSH(bucket)) {
+if (APR_BUCKET_IS_EOS(bucket)) {
+status = ssl_filter_io_shutdown(filter_ctx, f->c, 0);
+if (status) break;
+}
+
 if (bio_filter_out_flush(filter_ctx->pbioWrite) < 0) {
 status = outctx->rc;
 break;


<>

Re: FileSystem v.s. Other Resources [was configurable Location?]

[gregames]

William A. Rowe, Jr. wrote:
At 12:17 PM 2/5/2004, Joshua Slive wrote:


I do, however, agree that doing a directory-walk on virtual resources is
not nice.  But my opinion is that "virtualness" is a property of the
resource, and hence should be designated when selecting the resource.
That is why I suggested changing SetHandler rather than .
And perhaps I'm going way off in left field here, but why should this be
user-configurable at all?  Shouldn't the (for example) server-status
handler know itself that it is a virtual handler, and therefore indicate
that the directory-walk should be skipped?


For example, yes.  But on the other hand, what prevents someone from
removing the server-status handler in the fixups phase and tricking us into
serving a file.
sounds like we're getting into defense mechanisms against hypothetical malicious 
modules...  a loosing battle IMO

I'd like to see the default handler entirely detached from the request if the
dir_walk code has been bypassed.
if it's zero cost/dirt cheap in mainline code, I don't mind.

Greg

frustrating build experience *nix/windows

[Aryeh Katz]

I'd like to report a frustrating build experience, that is primarily a 
windows issue, but it highlights a 1.3/2.0 change.
In the 1.3 environment I was able to use the --shadow configure option 
to use the same source tree for multiple os's. This was quite valuable, 
as one source code change was needed for all platforms.
However, the --shadow option is gone in 2.0. That means I had to use 
--srcdir to accomplish the same results. All was fine until I came to 
windows. Then things blew up. Once I did my windows build, my unix build 
started pulling in all sorts of windows defines, despite the fact that 
it should have been using the os's include files. I tried to clean it 
up, but ended up just having to remove the whole tree, and start all 
over again.
And I think I'm not the only one that has this problem. I think everyone 
does. That's why there are two source packages, windows and UNIX.
Can someone tell me why the --shadow option was removed?
Aryeh
--
Aryeh Katz
SecureD Services
http://www.secured-services.com/
410 653 0700 x 2

Re: [PATCH] configurable Location block speed up

[gregames]

[EMAIL PROTECTED] wrote:

or Joshua's "virtual" keyword on , which I like better the 
more I think about it.
ooops... s/Joshua/André/

but Joshua has excellent points about "virtualness" being a property of the 
handler.  Yes, the server-status handler should know that it is virtual, but the 
handler hook is too late to skip the directory walk.  But the mod_status 
maintainers (i.e. us) know that mod_status is virtual, so maybe it could tell 
the core earlier somehow.  An earlier hook?  preferably something at config time 
since the virtualness doesn't ever change?

Greg

Re: cvs commit: httpd-2.0 buildconf

[gregames]

[EMAIL PROTECTED] wrote:

  * buildconf: Clean autoconf cache after running autoconf too.

  +# Remove autoconf 2.5x's cache directory
  +rm -rf autom4te*.cache
yay!

Greg

Re: [PATCH] configurable Location block speed up

[gregames]

moving to dev@ ... this deserves wider attention IMO

Geoffrey Young wrote:

one thing I was wondering about was the interaction between your patch an
mod_alias.  just by following the code without testing, it seems like either
mod_alias needs to unset the outside_filesystem flag for things like Alias
and ScriptAlias, 
something like that might work

or it needs to blow up over the conflict between those directives and your new directive.
or Joshua's "virtual" keyword on , which I like better the more I 
think about it.

But yeah, good point.  Unfortunately it adds complexity.  If the conflict could 
be detected at config time rather than run time, the added complexity does't 
bother me much at all.

that is, unless I'm reading the code wrong, or common setups like this

Alias /cgi-bin /usr/local/apache/cgi-bin

  SetHandler cgi-script
...
are also ones that you believe go against the existing documentation.

anyway, not a criticism (especially if I'm wrong), 
I think you're right.  Constructive critism is always welcome :)

just an observation.

--Geoff
No problem... excellent feedback.

Greg

Re: mod_ssl not sending Alert upon close ?

[Joe Orton]

On Thu, Feb 05, 2004 at 02:03:29PM -0800, Mathihalli, Madhusudan wrote:
> Okay. here's what I think is happening : (Client => C Server -> S)

You're right, the alert is never getting sent!

> C  -> S : initiates connection
> C <-> S : handshake
> S  -> C : server sends application data
> S  -> C : server tries to read from the socket
>   -> finds nothing (0 bytes returned)
>   -> assumes transaction is completed, and starts cleanup process
>   -> closes the connection first
>   -> frees the pool, which invokes ssl_io_filter_cleanup() and inturn 
> ssl_io_filter_shutdown()
>   -> ssl_io_filter_shutdown() tries to send 'Close notify'
>  OOPS ! The connection has already been terminated 

Yes - it's too late to rely on pool cleanups to send the alert: I think
the right place to do this is when the output filter gets the EOS
bucket: the patch below fixes for my tests, can you test against MSIE?

I'm not convinced about the ordering of the flush/shutdown...

--- modules/ssl/ssl_engine_io.c 23 Jan 2004 16:50:24 -  1.114
+++ modules/ssl/ssl_engine_io.c 6 Feb 2004 14:55:16 -
@@ -1404,6 +1404,11 @@
  * These types do not require translation by OpenSSL.  
  */
 if (APR_BUCKET_IS_EOS(bucket) || APR_BUCKET_IS_FLUSH(bucket)) {
+if (APR_BUCKET_IS_EOS(bucket)) {
+status = ssl_filter_io_shutdown(filter_ctx, f->c, 0);
+if (status) break;
+}
+
 if (bio_filter_out_flush(filter_ctx->pbioWrite) < 0) {
 status = outctx->rc;
 break;