Help required on Apache from scratch...

2004-02-24 Thread Benedict DSilva








Hi all,

 

Just wanted to know about how does the
Apache HTTP Server start, and all that it does with the modules (Initialization,
Configuration etc).

 

These are some of the points I wanted to
get cleared about!!

 

1. When Apache starts up what is all that
it does with the Modules 

   i.e How does it form its
linked list, and maintain the reference.

2. When ever a request is sent to Apache
server, then how does it process it?

  2.1 Does it
map the request to each and every module handler in the List?

  2.2 How are
all the phases then handled? Is it that for every phase of the request(URI
translation, auth, athoetc)  

 
all the modules actually consulted whether they can handle it?

 

Overall just wanted to know the working of the Apache Web
Server from Scratch.

 

Awaiting for a helping hand!

 

Thanks in Advance,

 

Warm Regards,

--BENNY

 








[PATCH-Modified] SSL not sending close alert message

2004-02-24 Thread Mathihalli, Madhusudan
Here's the new patch incorporating the feedback.

One thing that I'd like feedback : The eoc bucket is inserted by the 
ap_end_connection() function(in server/connection.c) - and deleted by SSL  in 
ssl_engine_io.c.  I don't feel comfortable with it.

Is that okay ? If not, what is a good place for inserting the EOC bucket (in mod_ssl) ?

Thanks
-Madhu

Index: server/connection.c
===
RCS file: /home/cvspublic/httpd-2.0/server/connection.c,v
retrieving revision 1.114
diff -u -r1.114 connection.c
--- server/connection.c 9 Feb 2004 20:40:49 -   1.114
+++ server/connection.c 25 Feb 2004 00:41:18 -
@@ -65,10 +65,23 @@
 #define MAX_SECS_TO_LINGER 30
 #endif

+AP_CORE_DECLARE(void) ap_end_connection(conn_rec *c)
+{
+apr_bucket_brigade *bb;
+apr_bucket *b;
+
+bb = apr_brigade_create(c->pool, c->bucket_alloc);
+b = ap_bucket_eoc_create(c->bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, b);
+ap_pass_brigade(c->output_filters, bb);
+}
+
 AP_CORE_DECLARE(void) ap_flush_conn(conn_rec *c)
 {
 apr_bucket_brigade *bb;
 apr_bucket *b;
+
+ap_end_connection(c);

 bb = apr_brigade_create(c->pool, c->bucket_alloc);
 b = apr_bucket_flush_create(c->bucket_alloc);
Index: include/http_protocol.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_protocol.h,v
retrieving revision 1.87
diff -u -r1.87 http_protocol.h
--- include/http_protocol.h 26 Jan 2004 22:08:06 -  1.87
+++ include/http_protocol.h 25 Feb 2004 00:42:48 -
@@ -666,6 +666,32 @@
  */
 AP_DECLARE_HOOK(apr_port_t,default_port,(const request_rec *r))

+AP_DECLARE_DATA extern const apr_bucket_type_t ap_bucket_type_eoc;
+
+/**
+ * Determine if a bucket is an End Of Connection (EOC) bucket
+ * @param e The bucket to inspect
+ * @return true or false
+ */
+#define AP_BUCKET_IS_EOC(e) (e->type == &ap_bucket_type_eoc)
+
+/**
+ * Make the bucket passed in an End Of Connection (EOC) bucket
+ * @param b The bucket to make into an EOC bucket
+ * @return The new bucket, or NULL if allocation failed
+ * @deffunc apr_bucket *ap_bucket_eoc_make(apr_bucket *b)
+ */
+AP_DECLARE(apr_bucket *) ap_bucket_eoc_make(apr_bucket *b);
+
+/**
+ * Create a bucket referring to an End Of Connection (EOC). This indicates
+ * that the connection will be closed.
+ * @param list The freelist from which this bucket should be allocated
+ * @return The new bucket, or NULL if allocation failed
+ * @deffunc apr_bucket *ap_bucket_eoc_create(apr_bucket_alloc_t *list)
+ */
+AP_DECLARE(apr_bucket *) ap_bucket_eoc_create(apr_bucket_alloc_t *list);
+
 typedef struct ap_bucket_error ap_bucket_error;

 /**
Index: modules/ssl/ssl_engine_io.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.117
diff -u -r1.117 ssl_engine_io.c
--- modules/ssl/ssl_engine_io.c 9 Feb 2004 20:29:22 -   1.117
+++ modules/ssl/ssl_engine_io.c 25 Feb 2004 01:16:28 -
@@ -100,6 +100,7 @@
 BIO*pbioWrite;
 ap_filter_t*pInputFilter;
 ap_filter_t*pOutputFilter;
+intnobuffer; /* non-zero to prevent buffering */
 } ssl_filter_ctx_t;

 typedef struct {
@@ -193,7 +194,8 @@
  */
 BIO_clear_retry_flags(bio);

-if (!outctx->length && (inl + outctx->blen < sizeof(outctx->buffer))) {
+if (!outctx->length && (inl + outctx->blen < sizeof(outctx->buffer)) &&
+!outctx->filter_ctx->nobuffer) {
 /* the first two SSL_writes (of 1024 and 261 bytes)
  * need to be in the same packet (vec[0].iov_base)
  */
@@ -1394,6 +1396,14 @@
  */
 apr_bucket_delete(bucket);
 }
+}
+else if (AP_BUCKET_IS_EOC(bucket)) {
+/* The special "EOC" bucket means a shutdown is needed;
+ * turn off buffering in bio_filter_out_write.
+ */
+filter_ctx->nobuffer = 1;
+status = ssl_filter_io_shutdown(filter_ctx, f->c, 0);
+apr_bucket_delete(bucket);
 }
 else {
 /* filter output */
Index: server/Makefile.in
===
RCS file: /home/cvspublic/httpd-2.0/server/Makefile.in,v
retrieving revision 1.91
diff -u -r1.91 Makefile.in
--- server/Makefile.in  2 Feb 2004 17:04:10 -   1.91
+++ server/Makefile.in  25 Feb 2004 00:44:05 -
@@ -13,7 +13,8 @@
connection.c listen.c \
mpm_common.c util_charset.c util_debug.c util_xml.c \
util_filter.c exports.c buildmark.c \
-   scoreboard.c error_bucket.c protocol.c core.c request.c provider.c
+   scoreboard.c error_bucket.c protocol.c core.c request.c provider.c \
+   eoc_bucket.c

 TARGETS = delete-exports $(LTLIBRARY_NAME) $(CORE_IMPLIB_FILE) export_vars.h httpd.exp

---

finish connection hook (WAS: RE: [PATCH] SSL not sending close alert message)

2004-02-24 Thread Mathihalli, Madhusudan

>-Original Message-
>From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
>
>mod_ssl-side I'd just use the changes in the most recent patch I posted
>with the CLOSE bucket test replaced with the EOC bucket test in the
>output filter: in my testing you needed to turn off buffering in
>bio_filter_out_write to get the shutdown logic working correctly.


... brings up the question : do you still want the finish_connection hook OR should 
the modules be content with the EOC bucket ?

-Madhu


Re: [PATCH] SSL not sending close alert message

2004-02-24 Thread Jim Jagielski
Cliff Woolley wrote:
> 
> On Tue, 24 Feb 2004, Joe Orton wrote:
> 
> > I wasn't sure whether or not this EOC bucket type should go in APR-util
> > or httpd.  Filtering gurus, what say ye?  That bit looks OK to me
> > otherwise with a licence header added to the new file.
> 
> I say httpd.
> 

+1

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson


RE: [PATCH] SSL not sending close alert message

2004-02-24 Thread Mathihalli, Madhusudan

>-Original Message-
>From: Cliff Woolley [mailto:[EMAIL PROTECTED]
[SNIP]
>On Tue, 24 Feb 2004, Joe Orton wrote:
>
>> I wasn't sure whether or not this EOC bucket type should go 
>in APR-util
>> or httpd.  Filtering gurus, what say ye?  That bit looks OK to me
>> otherwise with a licence header added to the new file.
>
>I say httpd.
>

server/eoc_bucket.c ?

-Madhu


RE: [PATCH] SSL not sending close alert message

2004-02-24 Thread Mathihalli, Madhusudan
Argh.. stupid e-mail client..

>
>>-Original Message-
>>From: Joe Orton [mailto:[EMAIL PROTECTED]
>[SNIP]
>>
>>I wasn't sure whether or not this EOC bucket type should go 
>in APR-util
>>or httpd.  Filtering gurus, what say ye?  That bit looks OK to me
>>otherwise with a licence header added to the new file.
>
>Since the EOC bucket is generic (and not limited to SSL type 
>filters), I thought the best place is in apr-util along with 
>other bucket types !
>
>
>>mod_ssl-side I'd just use the changes in the most recent 
>patch I posted
>>with the CLOSE bucket test replaced with the EOC bucket test in the
>>output filter: in my testing you needed to turn off buffering in
>>bio_filter_out_write to get the shutdown logic working correctly.
>>
>
>Well.. I'll try that out - but it appeared that if I release 
>the SSL buffer upon getting a EOC bucket - the shutdown data 
>(alert message) doesn't get flushed. That was the reason I'd 
>to use the shutdown_flag logic.
>

If the SSL context is released, the flush fails. Buffering is good - especially if we 
have huge amount data to be processed. I thought it's better not to disturb it.

-Madhu


Re: [PATCH] SSL not sending close alert message

2004-02-24 Thread Greg Stein
On Tue, Feb 24, 2004 at 06:15:20PM -0500, Cliff Woolley wrote:
> On Tue, 24 Feb 2004, Joe Orton wrote:
> 
> > I wasn't sure whether or not this EOC bucket type should go in APR-util
> > or httpd.  Filtering gurus, what say ye?  That bit looks OK to me
> > otherwise with a licence header added to the new file.
> 
> I say httpd.

Agreed.

-- 
Greg Stein, http://www.lyra.org/


RE: [PATCH] SSL not sending close alert message

2004-02-24 Thread Mathihalli, Madhusudan

>-Original Message-
>From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
>
>I wasn't sure whether or not this EOC bucket type should go in APR-util
>or httpd.  Filtering gurus, what say ye?  That bit looks OK to me
>otherwise with a licence header added to the new file.

Since the EOC bucket is generic (and not limited to SSL type filters), I thought the 
best place is in apr-util along with other bucket types !


>mod_ssl-side I'd just use the changes in the most recent patch I posted
>with the CLOSE bucket test replaced with the EOC bucket test in the
>output filter: in my testing you needed to turn off buffering in
>bio_filter_out_write to get the shutdown logic working correctly.
>

Well.. I'll try that out - but it appeared that if I release the SSL buffer upon 
getting a EOC bucket - the shutdown data (alert message) doesn't get flushed. That was 
the reason I'd to use the shutdown_flag logic.

-Madhu


Re: [PATCH] SSL not sending close alert message

2004-02-24 Thread Cliff Woolley
On Tue, 24 Feb 2004, Joe Orton wrote:

> I wasn't sure whether or not this EOC bucket type should go in APR-util
> or httpd.  Filtering gurus, what say ye?  That bit looks OK to me
> otherwise with a licence header added to the new file.

I say httpd.

--Cliff


Re: [PATCH] SSL not sending close alert message

2004-02-24 Thread Joe Orton
On Tue, Feb 24, 2004 at 09:59:00AM -0800, Mathihalli, Madhusudan wrote:
> >-Original Message-
> >From: Joe Orton [mailto:[EMAIL PROTECTED]
> [SNIP]
> >
> >This is just back to what we had patches for already: doing an SSL
> >shutdown on any EOF bucket, right?  Which is not right since you get an
> >EOS after each HTTP response, not at the end of the connection.
> >
> >Hence the need for a new bucket type to represent end-of-connection 
> >differently from EOS.
> >
> >(the test case for that is to see if you can send two requests on a
> >single SSL connection)
> 
> Okay - since I've not played much with buckets, here's my first
> attempt at getting something to work - please let me know if it's
> okay.

I wasn't sure whether or not this EOC bucket type should go in APR-util
or httpd.  Filtering gurus, what say ye?  That bit looks OK to me
otherwise with a licence header added to the new file.

mod_ssl-side I'd just use the changes in the most recent patch I posted
with the CLOSE bucket test replaced with the EOC bucket test in the
output filter: in my testing you needed to turn off buffering in
bio_filter_out_write to get the shutdown logic working correctly.

Thanks Madhu!

joe


[Patch]: Proposed patch to remove compile-time RequestLine length limit.

2004-02-24 Thread Paul J. Reder
The patch below is against current 2.1-dev head. It allows the user to
specify a LimitRequestLine value at config time and removes the compile-time
limits.
I'll commit this in a day or two if there are no comments to the contrary.
I just wanted to make sure I hadn't missed anything.
Thanks,

--
Paul J. Reder
---
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein


Index: httpd-2.0/server/core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.261
diff -u -r1.261 core.c
--- httpd-2.0/server/core.c 19 Feb 2004 11:19:43 -  1.261
+++ httpd-2.0/server/core.c 24 Feb 2004 17:36:35 -
@@ -2437,12 +2437,6 @@
"\" must be a non-negative integer", NULL);
 }
-if (lim > DEFAULT_LIMIT_REQUEST_LINE) {
-return apr_psprintf(cmd->temp_pool, "LimitRequestLine \"%s\" "
-"must not exceed the precompiled maximum of %d",
-arg, DEFAULT_LIMIT_REQUEST_LINE);
-}
-
 cmd->server->limit_req_line = lim;
 return NULL;
 }
Index: httpd-2.0/server/protocol.c
===
RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
retrieving revision 1.145
diff -u -r1.145 protocol.c
--- httpd-2.0/server/protocol.c 9 Feb 2004 20:40:49 -   1.145
+++ httpd-2.0/server/protocol.c 24 Feb 2004 17:36:36 -
@@ -577,11 +577,22 @@
  * if there are empty lines
  */
 r->the_request = NULL;
-rv = ap_rgetline(&(r->the_request), DEFAULT_LIMIT_REQUEST_LINE + 2,
+rv = ap_rgetline(&(r->the_request), (apr_size_t)(r->server->limit_req_line + 
2),
  &len, r, 0, bb);
 if (rv != APR_SUCCESS) {
 r->request_time = apr_time_now();
+
+/* ap_rgetline returns APR_ENOSPC if it fills up the
+ * buffer before finding the end-of-line.  This is only going to
+ * happen if it exceeds the configured limit for a request-line.
+ */
+if (rv == APR_ENOSPC) {
+r->status= HTTP_REQUEST_URI_TOO_LARGE;
+r->proto_num = HTTP_VERSION(1,0);
+r->protocol  = apr_pstrdup(r->pool, "HTTP/1.0");
+}
+
 return 0;
 }
 } while ((len <= 0) && (++num_blank_lines < max_blank_lines));
@@ -611,18 +622,6 @@
 ap_parse_uri(r, uri);

-/* ap_getline returns (size of max buffer - 1) if it fills up the
- * buffer before finding the end-of-line.  This is only going to
- * happen if it exceeds the configured limit for a request-line.
- * The cast is safe, limit_req_line cannot be negative
- */
-if (len > (apr_size_t)r->server->limit_req_line) {
-r->status= HTTP_REQUEST_URI_TOO_LARGE;
-r->proto_num = HTTP_VERSION(1,0);
-r->protocol  = apr_pstrdup(r->pool, "HTTP/1.0");
-return 0;
-}
-
 if (ll[0]) {
 r->assbackwards = 0;
 pro = ll;
@@ -856,7 +855,7 @@
 if (!read_request_line(r, tmp_bb)) {
 if (r->status == HTTP_REQUEST_URI_TOO_LARGE) {
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
-  "request failed: URI too long");
+  "request failed: URI too long (longer than %d)", 
r->server->limit_req_line);
 ap_send_error_response(r, 0);
 ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r);
 ap_run_log_transaction(r);



RE: [PATCH] SSL not sending close alert message

2004-02-24 Thread Mathihalli, Madhusudan
>-Original Message-
>From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
>
>This is just back to what we had patches for already: doing an SSL
>shutdown on any EOF bucket, right?  Which is not right since you get an
>EOS after each HTTP response, not at the end of the connection.
>
>Hence the need for a new bucket type to represent end-of-connection 
>differently from EOS.
>
>(the test case for that is to see if you can send two requests on a
>single SSL connection)


Okay - since I've not played much with buckets, here's my first attempt at getting 
something to work - please let me know if it's okay.

Logic:
-> When ap_flush_conn() is called (always before apr_socket_close()), create a EOC 
bucket and pass it on
-> In the SSL (output) filter, invoke SSL_shutdown but don't free the SSL context as 
it's required for the flush that happens later
-> ssl_filter_io_shutdown() takes a extra flag for freeing the SSL context (when a EOC 
is received, it just sends the SSL_shutdown but doesn't do the free)

Patch:
---
NEW FILE: apr-util/buckets/apr_buckets_eoc.c
---

#include "apr_buckets.h"

static apr_status_t eoc_bucket_read(apr_bucket *b, const char **str,
apr_size_t *len, apr_read_type_e block)
{
*str = NULL;
*len = 0;
return APR_SUCCESS;
}

APU_DECLARE(apr_bucket *) apr_bucket_eoc_make(apr_bucket *b)
{
b->length  = 0;
b->start   = 0;
b->data= NULL;
b->type= &apr_bucket_type_eoc;

return b;
}

APU_DECLARE(apr_bucket *) apr_bucket_eoc_create(apr_bucket_alloc_t *list)
{
apr_bucket *b = apr_bucket_alloc(sizeof(*b), list);

APR_BUCKET_INIT(b);
b->free = apr_bucket_free;
b->list = list;
return apr_bucket_eoc_make(b);
}

APU_DECLARE_DATA const apr_bucket_type_t apr_bucket_type_eoc = {
"EOC", 5, APR_BUCKET_METADATA,
apr_bucket_destroy_noop,
eoc_bucket_read,
apr_bucket_setaside_noop,
apr_bucket_split_notimpl,
apr_bucket_simple_copy
};

---
END of apr_buckets_eoc.c
---

Index: apr-util/include/apr_buckets.h
===
RCS file: /home/cvspublic/apr-util/include/apr_buckets.h,v
retrieving revision 1.156
diff -u -r1.156 apr_buckets.h
--- apr_buckets.h   13 Feb 2004 09:55:26 -  1.156
+++ apr_buckets.h   24 Feb 2004 17:46:31 -
@@ -453,6 +453,12 @@
  */
 #define APR_BUCKET_IS_FLUSH(e)   ((e)->type == &apr_bucket_type_flush)
 /**
+ * Determine if a bucket is an End Of Connection (EOC) bucket
+ * @param e The bucket to inspect
+ * @return true or false
+ */
+#define APR_BUCKET_IS_EOC(e) ((e)->type == &apr_bucket_type_eoc)
+/**
  * Determine if a bucket is an EOS bucket
  * @param e The bucket to inspect
  * @return true or false
@@ -1056,6 +1062,11 @@
  */
 APU_DECLARE_DATA extern const apr_bucket_type_t apr_bucket_type_flush;
 /**
+ * The End Of Connection (EOC) bucket type. This signifies that the
+ * connection will be closed.
+ */
+APU_DECLARE_DATA extern const apr_bucket_type_t apr_bucket_type_eoc;
+/**
  * The EOS bucket type.  This signifies that there will be no more data, ever.
  * All filters MUST send all data to the next filter when they receive a
  * bucket of this type
@@ -1202,6 +1213,21 @@
  * other code should call apr_bucket_foo_create. All the initialization
  * functions change nothing if they fail.
  */
+
+/**
+ * Create an End of Connection (EOC) bucket. This indicates that the
+ * connection will be closed.
+ * @param list The freelist from which this bucket should be allocated
+ * @return The new bucket, or NULL if allocation failed
+ */
+APU_DECLARE(apr_bucket *) apr_bucket_eoc_create(apr_bucket_alloc_t *list);
+
+/**
+ * Make the bucket passed in an End Of Connection (EOC) bucket.
+ * @param b The bucket to make into an EOC bucket
+ * @return The new bucket, or NULL if allocation failed
+ */
+APU_DECLARE(apr_bucket *) apr_bucket_eoc_make(apr_bucket *b);

 /**
  * Create an End of Stream bucket.  This indicates that there is no more data

Index: httpd-2.0/server/connection.c
===
RCS file: /home/cvspublic/httpd-2.0/server/connection.c,v
retrieving revision 1.111
diff -u -r1.111 connection.c
--- server/connection.c 1 Jan 2004 13:26:23 -   1.111
+++ server/connection.c 24 Feb 2004 17:24:27 -
@@ -108,10 +108,23 @@
 #define MAX_SECS_TO_LINGER 30
 #endif

+AP_CORE_DECLARE(void) ap_end_connection(conn_rec *c)
+{
+apr_bucket_brigade *bb;
+apr_bucket *b;
+
+bb = apr_brigade_create(c->pool, c->bucket_alloc);
+b = apr_bucket_eoc_create(c->bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, b);
+ap_

something for you

2004-02-24 Thread sussman
you earn money
<>


jk2 hooks infos

2004-02-24 Thread Henri Gomez
Hi to all,

I'm working on jk2 release (2.0.4) and as such try to fix
many bugzillas.
Jean-Frederic Clere send me this nice article (in french) :

http://www.hsc.fr/ressources/breves/apache-modules.html.fr

It seems there is a patch against mod_jk2 (we're working
jk2 release) :
--- mod_jk2.c.orig  2004-01-26 17:31:04.0 +0100
+++ mod_jk2.c   2004-01-26 17:30:48.0 +0100
@@ -808,11 +808,14 @@
 static void jk2_register_hooks(apr_pool_t *p)
 {
+static const char * const aszPre[]={ "mod_rewrite.c",NULL };
+
 ap_hook_handler(jk2_handler, NULL, NULL, APR_HOOK_MIDDLE);
 ap_hook_post_config(jk2_post_config,NULL,NULL,APR_HOOK_MIDDLE);
 /* Force the mpm to run before us and set the
 * scoreboard image */
 ap_hook_child_init(jk2_child_init,NULL,NULL,APR_HOOK_LAST);
-ap_hook_translate_name(jk2_translate,NULL,NULL,APR_HOOK_FIRST);
+// ap_hook_translate_name(jk2_translate,NULL,NULL,APR_HOOK_FIRST);
+ap_hook_translate_name(jk2_translate, aszPre,NULL,APR_HOOK_FIRST);
 ap_hook_map_to_storage(jk2_map_to_storage, NULL, NULL, 
APR_HOOK_MIDDLE);
 }

I wonder if we should use it since I saw in mod_file_cache.c (2.0.48),
that this tricks didn't works.
Who's right ?





Re: interface of the 2.1 authentication framework / behaviour of mod_digest/mod_basic

2004-02-24 Thread Axel Grossklaus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Geoffrey Young wrote:

moin,

> yeah, that would certainly be a good idea. give the attached patches a
whirl
> and see if they work for you.  feedback from justin or others that are
> familiar appreciated :)


thanks. that takes care of one half of my mail.

how about the other half, i.e. change of the auth-interface?

i would be really happy to get some feedback on that...

justin maybe?


tty, axel

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAOxeLHAHtNfez9GYRAiGYAKCIqXuSBAzLhaH4PKrHRyzq5EgrRwCdEu+2
eHIeVkaUQsTCN7RTi52lL5w=
=HGhr
-END PGP SIGNATURE-