Re: How to change ap_document_root variable from a apache2 module ?
On Thu, 30 Dec 2004, Paul Querna wrote: > > Whether it is against the design or not, it is a useful thing to be able > > to do. And I fully realize that my module can do whatever it wants, but > > other modules won't know about it unless I modify them. > > I agree this could be a useful 'feature'. Not sure what "this" you have in mind here. A change to the semantics of document root will break things. Do you mean you think it would be useful to introduce another call - e.g. ap_request_root to get a per-request root path independent of r->filename ? > I believe in a new API for > configuration, this should be taken into consideration. However, the > current hack of overwriting the values of a CORE config struct is > completely bogus. Indeed, it'll break any module that uses it correctly. > > This can be done quite safely in Apache1, by the way. > > I don't believe it can. Code? Well, you can change the env var DOCUMENT_ROOT, as that's a per-request thing. But that's a grotty hack that relies on apps that use it not caring about being messed with. Very nasty if, for example, someone is using mod_rewrite (before the change) together with a CGI (after) and *expecting* it not to change between the two. -- Nick Kew
Re: How to change ap_document_root variable from a apache2 module ?
On Thu, 30 Dec 2004, Paul Querna wrote: > Rasmus Lerdorf wrote: > [snip] > >>Hint: document root is a configuration value used *by default* in > >>filename translation. Any module can implement its own translation > >>hook, but trying to change a core configuration value is not only > >>utterly pointless (your module can use its own variables), it's > >>working against the apache design, even in a non-threaded MPM. > > > > > > Whether it is against the design or not, it is a useful thing to be able > > to do. And I fully realize that my module can do whatever it wants, but > > other modules won't know about it unless I modify them. > > I agree this could be a useful 'feature'. I believe in a new API for > configuration, this should be taken into consideration. However, the > current hack of overwriting the values of a CORE config struct is > completely bogus. > > > > > This can be done quite safely in Apache1, by the way. > > I don't believe it can. Code? Well, since you don't need to worry about thread safety as long as you set it on every request, or reset it after each request you are fine. Something like: foo->old = ap_document_root(r); conf = ap_get_module_config(s->module_config, &core_module); conf->ap_document_root = new; ap_register_cleanup(r->pool, foo, my_cleanup, ap_null_cleanup); Then set it back to foo->old in my_cleanup(). And yes, I agree it is a hack to change anything in the core_module on a per-request basis, but there are a lot of things that are very useful hacks in Apache1 that I am hoping to see the richer and more flexible Apache2 API address. -Rasmus
Re: How to change ap_document_root variable from a apache2 module ?
Rasmus Lerdorf wrote: [snip] Hint: document root is a configuration value used *by default* in filename translation. Any module can implement its own translation hook, but trying to change a core configuration value is not only utterly pointless (your module can use its own variables), it's working against the apache design, even in a non-threaded MPM. Whether it is against the design or not, it is a useful thing to be able to do. And I fully realize that my module can do whatever it wants, but other modules won't know about it unless I modify them. I agree this could be a useful 'feature'. I believe in a new API for configuration, this should be taken into consideration. However, the current hack of overwriting the values of a CORE config struct is completely bogus. This can be done quite safely in Apache1, by the way. I don't believe it can. Code?
Re: How to change ap_document_root variable from a apache2 module ?
On Fri, 31 Dec 2004, Nick Kew wrote: > On Thu, 30 Dec 2004, Rasmus Lerdorf wrote: > > > Nobody is saying anything about doing it anywhere within a request. > > Huh? What are you smoking? > > > obviously you can't change the doc_root after the fact, but I see no > > reason to not be able to do it prior to each request in the filename > > translation hook > > Erm, where can I find a filename translation hook outside the request? You can't, but the translation hook is not *anywhere* within the request, it is at the beginning. > > so other hooks which use the doc_root will function > > correctly. > > Hint: document root is a configuration value used *by default* in > filename translation. Any module can implement its own translation > hook, but trying to change a core configuration value is not only > utterly pointless (your module can use its own variables), it's > working against the apache design, even in a non-threaded MPM. Whether it is against the design or not, it is a useful thing to be able to do. And I fully realize that my module can do whatever it wants, but other modules won't know about it unless I modify them. This can be done quite safely in Apache1, by the way. -Rasmus
Re: How to change ap_document_root variable from a apache2 module ?
On Thu, 30 Dec 2004, Rasmus Lerdorf wrote: > Nobody is saying anything about doing it anywhere within a request. Huh? What are you smoking? > obviously you can't change the doc_root after the fact, but I see no > reason to not be able to do it prior to each request in the filename > translation hook Erm, where can I find a filename translation hook outside the request? >so other hooks which use the doc_root will function > correctly. Hint: document root is a configuration value used *by default* in filename translation. Any module can implement its own translation hook, but trying to change a core configuration value is not only utterly pointless (your module can use its own variables), it's working against the apache design, even in a non-threaded MPM. -- Nick Kew
Re: How to change ap_document_root variable from a apache2 module ?
On Fri, 31 Dec 2004, Nick Kew wrote: > On Thu, 30 Dec 2004, Paul Querna wrote: > > > > Just sets the root server's docroot then now. Not being able able to > > > manipulate the document_root is a rather severe limitation as far as I am > > > concerned. > > > > I agree. But to fix it properly, we need a different system for doing > > configuration stuff. The current system is just no good for doing stuff > > on demand/on request. > > Huh? Why is this a problem? A module might just have a legitimate > reason to change document_root at post_config. But to do so anywhere > within a request is nonsense: by all means set file paths (c.f. Alias, > etc), but don't call it document root. Nobody is saying anything about doing it anywhere within a request. obviously you can't change the doc_root after the fact, but I see no reason to not be able to do it prior to each request in the filename translation hook so other hooks which use the doc_root will function correctly. -Rasmus
Re: How to change ap_document_root variable from a apache2 module ?
On Thu, 30 Dec 2004, Paul Querna wrote: > > Just sets the root server's docroot then now. Not being able able to > > manipulate the document_root is a rather severe limitation as far as I am > > concerned. > > I agree. But to fix it properly, we need a different system for doing > configuration stuff. The current system is just no good for doing stuff > on demand/on request. Huh? Why is this a problem? A module might just have a legitimate reason to change document_root at post_config. But to do so anywhere within a request is nonsense: by all means set file paths (c.f. Alias, etc), but don't call it document root. -- Nick Kew
Re: How to change ap_document_root variable from a apache2 module ?
Rasmus Lerdorf wrote: On Thu, 30 Dec 2004, Paul Querna wrote: It is impossible with the current way virtual hosts and document roots are handled. I guess doing it per-conf Apache1-style, as in: conf = ap_get_module_config() conf->ap_document_root = ...; This is not safe in a multi-threaded MPM, IIRC. Just sets the root server's docroot then now. Not being able able to manipulate the document_root is a rather severe limitation as far as I am concerned. I agree. But to fix it properly, we need a different system for doing configuration stuff. The current system is just no good for doing stuff on demand/on request.
Re: How to change ap_document_root variable from a apache2 module ?
On Thu, 30 Dec 2004, Paul Querna wrote: > It is impossible with the current way virtual hosts and document roots > are handled. I guess doing it per-conf Apache1-style, as in: conf = ap_get_module_config() conf->ap_document_root = ...; Just sets the root server's docroot then now. Not being able able to manipulate the document_root is a rather severe limitation as far as I am concerned. -Rasmus
Re: How to change ap_document_root variable from a apache2 module ?
Xavier Beaudouin wrote: Hello there, First appology me if my english is bad or if I sent this question to the wrong mailing list, since I have search a lot with google and was not able to find any good hint about that kind of question. I am making a module for apache2 only that does Virtual Hosting System within SQL or LDAP backend. The module is based on heavy modified mod_vdbh and some functionalities from me. Seen mod_vhost_dbi? http://www.outoforder.cc/projects/apache/mod_vhost_dbi/ I am the author... I have one problem is to set internal variable from Apache 2 (DOCUMENT_ROOT) to the correct value (intead of getting the global one all the time). It is impossible with the current way virtual hosts and document roots are handled. -Paul Querna
Re: C-L or T-E: chunked for proxied request bodies
On Thu, 30 Dec 2004, Jeff Trawick wrote: > 1. special case: > if client specified C-L and either C-L is zero or there are no > input filters or some magic envvar is set to indicate that filters > don't change the size: > pass through the C-L header and stream the request body, if any > > 2. normal: >read enough request body to see if there is more than 32K of > request body... >if <= 32K: > send the C-L and the small request body; >else if some magic variable is set to force calculation of C-L: > get temporary file; > read entire request body into file; > send calculated C-L; > send request body from the file; > else: > use chunked encoding and stream the request body Hey, I was just drafting a reply in this thread, but you beat me to it:-) +1 to the above. > > Will there really remain no active filters in the common case? > > strictly speaking, there are always filters; but we're just worried > about filters which can modify the request body; it is common to have > a configuration in which there are no filters which modify the request > body... This is essentially what the protocol handling in mod_filter offers for output filters. I wonder if you've just made the case (always "potentially useful/interesting") to extend mod_filter to input filters? -- Nick Kew
Re: C-L or T-E: chunked for proxied request bodies
On Thu, 30 Dec 2004 21:12:16 +0100, Jan Kratochvil <[EMAIL PROTECTED]> wrote: > Hi, > > On Thu, 30 Dec 2004 19:54:05 +0100, Jeff Trawick wrote: > > On Thu, 30 Dec 2004 18:47:48 +0100, Jan Kratochvil > > <[EMAIL PROTECTED]> wrote: > ... > > An interesting issue is that what is in 2.0 now is optimal when it > > works, and it works in a common real-world scenario (client sends C-L > > and no filters modify the request body size). > > Sorry for chatting without code sample etc. > > * If no active filters are detected after headers parsing pass the > single request unchanged through this connection by its C-L despite > its possible "keepalive". that's the goal of the patch I posted earlier this afternoon; I didn't consider keepalive setting and hope it is irrelevant ;) > * Use currently 2.1-implemented C-E "chunked" as fallback. for the very short term, I agree; if my prior patch to try to preserve some of the optimal handling in 2.0 is acceptable, then we could fall back to chunked for the long term, here is my current understanding of a better solution. 1. special case: if client specified C-L and either C-L is zero or there are no input filters or some magic envvar is set to indicate that filters don't change the size: pass through the C-L header and stream the request body, if any 2. normal: read enough request body to see if there is more than 32K of request body... if <= 32K: send the C-L and the small request body; else if some magic variable is set to force calculation of C-L: get temporary file; read entire request body into file; send calculated C-L; send request body from the file; else: use chunked encoding and stream the request body > Will there really remain no active filters in the common case? strictly speaking, there are always filters; but we're just worried about filters which can modify the request body; it is common to have a configuration in which there are no filters which modify the request body... > At least ap_byterange_filter() gives up but chunk_filter() never does. > Is it possible to patch such filters? It would be performance wise. :-) those two filters aren't used on input, and they aren't used when forwarding the request to the origin server
Re: [Patch 30399] New directive CacheIgnoreHeaders to prevent user defined headers from being stored by mod_cache
On Thu, 30 Dec 2004, Dick Snippe wrote: > cachable pages. Prior to apache 2.0.50 this wasn't a very big issue; these > pages would be cached, many people would be using the same cookie and that > was that. However, after apache-2.0.50 apache would store cookies as well. > This resulted in storing multiple cookies for the same web page which > confused tomcat to the point of breaking. Can you not work around this with your own "Header set" directives to override your application's cookies with the proxy's own, or indeed unset them? I'm not suggesting this as an alternative to the patch, but rather as a workaround that'll fix it for you with httpd-2.0.5x as-is now. > Fortunately the CacheIgnoreHeaders patch solves exactly this problem for us! > We use it in production on rather busy sites and it works perfectly. > Since I'd rather use regular apache-2.0.x versions instead of CVS checkouts, > I'd like to see this patch backported to 2.0.x, please. Nothing against backporting the patch, but I'd need to review it before voting +1 (as opposed to +0). -- Nick Kew
Re: C-L or T-E: chunked for proxied request bodies
Hi, On Thu, 30 Dec 2004 19:54:05 +0100, Jeff Trawick wrote: > On Thu, 30 Dec 2004 18:47:48 +0100, Jan Kratochvil > <[EMAIL PROTECTED]> wrote: ... > An interesting issue is that what is in 2.0 now is optimal when it > works, and it works in a common real-world scenario (client sends C-L > and no filters modify the request body size). Sorry for chatting without code sample etc. * If no active filters are detected after headers parsing pass the single request unchanged through this connection by its C-L despite its possible "keepalive". * Use currently 2.1-implemented C-E "chunked" as fallback. Will there really remain no active filters in the common case? At least ap_byterange_filter() gives up but chunk_filter() never does. Is it possible to patch such filters? It would be performance wise. :-) Regards, Lace
Re: How to debug HTTP Server in Windows with VC6.0
From: "nian li" I want to know how to debug HTTP Server in Windows with VC6.0. There is another way too. Windows Scripting, the best tool ever for Apache on Windows usage for both developers and admins. :) You can get a crash dump on the production box and then take it back to a dev box where you have symbols to find out the cause of the crash. Snip ADPlus is a new tool from Microsoft Product Support Services (PSS) that can troubleshoot any process or application that stops responding (hangs) or fails (crashes). Snip Frequently, you can use ADPlus (ADPlus.vbs) as a replacement tool for the Microsoft Internet Information Server (IIS) Exception Monitor (6.1/7.1) and User Mode Process Dump. These are two separate tools that PSS frequently uses to isolate what causes a process to stop responding (hang) or quit unexpectedy (crash) in a Microsoft Windows DNA environment. Snip ADPlus works with any user mode process or service such as Internet Information Services (IIS), Microsoft Transaction Server (MTS), or Microsoft COM+ applications. Snip ADPlus is console-based Microsoft Visual Basic script. It automates the Microsoft CDB debugger to produce memory dumps and log files that contain debug output from one or more processes. How To Use ADPlus to Troubleshoot "Hangs" and "Crashes" http://support.microsoft.com/?id=286350 Thanks Brian [MSFT] Microsoft Developer Support Learn more about Windows Scripting with the language of your desire too. Browse the script Repository http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx Scripting Languages Available in the Script Center http://www.microsoft.com/technet/scriptcenter/scripts/language.mspx Jeff
Re: C-L or T-E: chunked for proxied request bodies
On Thu, 30 Dec 2004 13:54:05 -0500, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> An interesting issue is that what is in 2.0 now is optimal when it
> works, and it works in a common real-world scenario (client sends C-L
> and no filters modify the request body size). At present, we don't
> have any proposed solution which would preserve this common, optimal
> situation. That will be a painful regression for some, since the
> request body will be buffered in memory in order to re-calculate the
> C-L.
Here is a patch which preserves the C-L setting and streams the
request body when the client specified C-L and there are no input
filters which could possibly muck with the request body. (Some
filters might be in place which don't modify the request body length,
but we can't check that. An envvar could be used to indicate that it
is safe to preserve the C-L even though there is an input filter.)
Index: modules/proxy/proxy_http.c
===
--- modules/proxy/proxy_http.c (revision 123727)
+++ modules/proxy/proxy_http.c (working copy)
@@ -247,7 +247,7 @@
apr_bucket *e, *last_header_bucket = NULL;
const apr_array_header_t *headers_in_array;
const apr_table_entry_t *headers_in;
-int counter, seen_eos, send_chunks;
+int counter, seen_eos, send_chunks, same_cl;
apr_status_t status;
apr_bucket_brigade *header_brigade, *body_brigade, *input_brigade;
apr_off_t transferred = 0;
@@ -282,15 +282,26 @@
/* By default, we can not send chunks. That means we must buffer
* the entire request before sending it along to ensure we have
- * the correct Content-Length attached.
+ * the correct Content-Length attached. A special case is when
+ * the client specifies Content-Length and there are no filters
+ * to muck with the request body. In that situation, we don't
+ * have to buffer the entire request and can still send the
+ * Content-Length.
*/
+
+same_cl = 0;
send_chunks = 0;
+if (apr_table_get(r->headers_in, "Content-Length") &&
+r->input_filters == r->proto_input_filters) {
+same_cl = 1; /* content-length will remain the same */
+}
+
if (apr_table_get(r->subprocess_env, "force-proxy-request-1.0")) {
buf = apr_pstrcat(p, r->method, " ", url, " HTTP/1.0" CRLF, NULL);
} else {
buf = apr_pstrcat(p, r->method, " ", url, " HTTP/1.1" CRLF, NULL);
-if (apr_table_get(r->subprocess_env, "proxy-sendchunks")) {
+if (!same_cl && apr_table_get(r->subprocess_env, "proxy-sendchunks")) {
send_chunks = 1;
}
}
@@ -470,6 +481,15 @@
e = apr_bucket_pool_create(buf, sizeof(te_hdr)-1, p, c->bucket_alloc);
APR_BRIGADE_INSERT_TAIL(header_brigade, e);
}
+else if (same_cl) {
+buf = apr_pstrcat(p, "Content-Length: ",
+ apr_table_get(r->headers_in, "Content-Length"),
+ CRLF,
+ NULL);
+ap_xlate_proto_to_ascii(buf, strlen(buf));
+e = apr_bucket_pool_create(buf, strlen(buf), p, c->bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(header_brigade, e);
+}
else {
last_header_bucket = APR_BRIGADE_LAST(header_brigade);
}
@@ -487,7 +507,7 @@
apr_brigade_length(header_brigade, 0, &transferred);
if (transferred != -1)
conn->worker->s->transferred += transferred;
-if (send_chunks) {
+if (send_chunks || same_cl) {
status = ap_pass_brigade(origin->output_filters, header_brigade);
if (status != APR_SUCCESS) {
@@ -550,7 +570,7 @@
e = apr_bucket_immortal_create(ASCII_CRLF, 2, c->bucket_alloc);
APR_BRIGADE_INSERT_TAIL(input_brigade, e);
}
-else {
+else if (!same_cl) {
/* The send_chunks case does not need to be setaside, but this
* case does because we may have transient buckets that may get
* overwritten in the next iteration of the loop.
@@ -567,7 +587,7 @@
APR_BRIGADE_CONCAT(body_brigade, input_brigade);
-if (send_chunks) {
+if (send_chunks || same_cl) {
status = ap_pass_brigade(origin->output_filters, body_brigade);
if (status != APR_SUCCESS) {
@@ -591,7 +611,7 @@
APR_BRIGADE_INSERT_TAIL(body_brigade, e);
}
-if (!send_chunks) {
+if (!send_chunks && !same_cl) {
apr_off_t bytes;
apr_brigade_length(body_brigade, 1, &bytes);
Re: C-L or T-E: chunked for proxied request bodies
On Thu, 30 Dec 2004 18:47:48 +0100, Jan Kratochvil <[EMAIL PROTECTED]> wrote: > On Thu, 30 Dec 2004 14:05:30 +0100, Jeff Trawick wrote: > > On 29 Dec 2004 20:39:47 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > ... > > Any agreement to use the non-DOS-able and protocol-compliant > > implementation by default, and allow the C-L method to be enabled by a > > special setting? > > Is it going to be backported to 2.0 or it waits for 2.2? It is very likely that whatever ends up in 2.2, possibly different than in current snapshots, will be backported. The only reason it hasn't been backported yet is that there are some concerns with what is in the current snapshots. And such concerns surely apply to 2.2 as well, so something has to be done ;) An interesting issue is that what is in 2.0 now is optimal when it works, and it works in a common real-world scenario (client sends C-L and no filters modify the request body size). At present, we don't have any proposed solution which would preserve this common, optimal situation. That will be a painful regression for some, since the request body will be buffered in memory in order to re-calculate the C-L. --/-- Oddity in the current 2.1 snapshot solution: If you set the proxy-sendchunked variable, then the origin server will always get a request body, even if the client didn't send one. A simple GET from the client turns into this: G E T / s i l l y / / s e n d c h u n k s / ? r e a d _ b o d y H T T P / 1 . 1\r\n H o s t : 1 2 7 . 0 . 0 . 1 : 8 0 8 1 \r\n M a x - F o r w a r d s : 1 0\r\n C o n n e c t i o n : c l o s e\r\n X - F o r w a r d e d - F o r : 1 2 7 . 0 . 0 . 1\r\n X - F o r w a r d e d - H o s t : 1 2 7 . 0 . 0 . 1\r\n X - F o r w a r d e d - S e r v e r : 1 9 2 . 1 6 8 . 1 . 1 1 \r\n T r a n s f e r - E n c o d i n g : c h u n k e d\r\n\r\n 0\r\n\r\n
Re: How to debug HTTP Server in Windows with VC6.0
(The spirit of this answer applies to gcc as well)... The easiest way is to change the arguments to Apache.exe (httpd) to include the -X flag. This means you are debugging the instance that runs the request, and not the usual parent process which is overseeing that child-worker processes exist. Add the -X flag to your desired -d and -f arguments. Remember that if you haven't copied the .pdb files to the install tree, the child modules can't be debugged. Use the Apache project as the project to 'debug'. (This is similar to gdb 'unstripped' binaries.) At 01:50 AM 12/30/2004, nian li wrote: >Hi all, > >Don't know if I send the mail to correct mailing list. If not, please >correct me. > >I want to know how to debug HTTP Server in Windows with VC6.0. Now I >can open the Apache.dsw workspace, but there are a lot of subprojects. >If I debug the Apache subproject, it seems the related configration >files and dll files do not exist. > >Any feedback will be highly appreciated. > >Thanks >-Nian
Re: C-L or T-E: chunked for proxied request bodies
Hi Jeff, On Thu, 30 Dec 2004 14:05:30 +0100, Jeff Trawick wrote: > On 29 Dec 2004 20:39:47 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: ... > Any agreement to use the non-DOS-able and protocol-compliant > implementation by default, and allow the C-L method to be enabled by a > special setting? Is it going to be backported to 2.0 or it waits for 2.2? Thanks, Lace
How to change ap_document_root variable from a apache2 module ?
Hello there,
First appology me if my english is bad or if I sent this question to
the wrong mailing list, since I have
search a lot with google and was not able to find any good hint about
that kind of question.
I am making a module for apache2 only that does Virtual Hosting System
within SQL or LDAP backend.
The module is based on heavy modified mod_vdbh and some functionalities
from me.
I have one problem is to set internal variable from Apache 2
(DOCUMENT_ROOT) to the correct value (intead of getting
the global one all the time).
I have a module like that (parts of my source code) :
static void register_hooks(apr_pool_t *p)
{
ap_hook_post_config(vhs_init_handler, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_translate_name(vhs_translate_name, NULL, NULL, APR_HOOK_FIRST);
}
AP_DECLARE_DATA module vhs_module = {
STANDARD20_MODULE_STUFF,
NULL, /* create per-directory config structure */
NULL, /* merge per-directory config structures */
vhs_create_server_config, /* create per-server config structure */
vhs_merge_server_config,/* merge per-server config structures */
vhs_commands, /* command apr_table_t */
register_hooks /* register hooks */
};
on
static int vhs_translate_name(request_rec *r)
{
char *document_root;
/*
* Usual works and data handling
*/
return OK;
}
How can I set the document root variable to value from document_root
variable in vhs_translate_name correctly ?
I can set a third party variable using for example :
apr_table_set(r->subprocess_env, "VH_DOCUMENT_ROOT", document_root);
But I never been able to change the conf->ap_document_root variable
correctly even with taking some source code
from core.c of apache 2.
Please help me to get the right way to do that...
Many thanks, and happy new year for all,
/Xavier
--
Xavier Beaudouin - Unix System Administrator & Projects Leader.
President of Kazar Organization : http://www.kazar.net/
Please visit http://caudium.net/, home of Caudium & Camas projects
Re: [Patch 30399] New directive CacheIgnoreHeaders to prevent user defined headers from being stored by mod_cache
On Sat, Oct 23, 2004 at 10:46:52AM -0700, Justin Erenkrantz wrote: > --On Friday, October 15, 2004 10:48 AM +0200 R?diger Pl?m > <[EMAIL PROTECTED]> wrote: > > >please find attached a new more general approch to prevent cookies from > >being stored in the cache. > >As proposed by Justin I replaced my original CacheStoreCookies directive > >with the more > >general CacheIgnoreHeaders directive. So far I only tested it for myself. > >If someone could test / have a look at it, it would be nice and > >appreciated. > >Meanwhile I try to > >get additional testers and will report about the results later. > > Looks good. I committed a variant of the patch to HEAD, and have proposed > it for backport to 2.0.x. Thanks! -- justin I'd like to see this patch backported to 2.0.x as well. At our jsp sites (approx 6 million hits per day) we use apache as a reverse caching proxy for tomcat. Tomcat (that is to say: the j2ee spec) more or less insists on creating sessions for everything. Often, web-applications built by third parties don't get all the details of setting http caching headers exactly right (if at all,..) So, we often see Set-cookie headers on cachable pages. Prior to apache 2.0.50 this wasn't a very big issue; these pages would be cached, many people would be using the same cookie and that was that. However, after apache-2.0.50 apache would store cookies as well. This resulted in storing multiple cookies for the same web page which confused tomcat to the point of breaking. Because of this we're more or less forced to keep on using 2.0.49 until all webapps are fixed. Most webapps however will probably never be fixed, so we may have to resort to extrema measures as putting apache-2.0.52 in front of apache-2.0.49, as in: internet--2.0.52[without caching]--2.0.49[with caching]--tomcat Fortunately the CacheIgnoreHeaders patch solves exactly this problem for us! We use it in production on rather busy sites and it works perfectly. Since I'd rather use regular apache-2.0.x versions instead of CVS checkouts, I'd like to see this patch backported to 2.0.x, please. -- Dick Snippe - Publieke Omroep Internet Services Mediacentrum kamer 138 Sumatralaan 45 Hilversum \ fight war tel +31 35 6774252, email [EMAIL PROTECTED] []() \ not wars
Re: How to debug HTTP Server in Windows with VC6.0
This seems easy enough: Build a debug Apache executable with the InstallBin project. Run it. Debug the process at your leisure (Task Manager -> Processes -> Debug, etc). -- Jess Holle nian li wrote: Hi all, Don't know if I send the mail to correct mailing list. If not, please correct me. I want to know how to debug HTTP Server in Windows with VC6.0. Now I can open the Apache.dsw workspace, but there are a lot of subprojects. If I debug the Apache subproject, it seems the related configration files and dll files do not exist. Any feedback will be highly appreciated. Thanks -Nian
C-L or T-E: chunked for proxied request bodies
On 29 Dec 2004 20:39:47 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: trawick > Date: Wed Dec 29 12:39:46 2004 > New Revision: 123674 > > URL: http://svn.apache.org/viewcvs?view=rev&rev=123674 > Log: > does anyone remember this proxy issue? > > Modified: >httpd/httpd/branches/2.0.x/STATUS > > Modified: httpd/httpd/branches/2.0.x/STATUS > Url: > http://svn.apache.org/viewcvs/httpd/httpd/branches/2.0.x/STATUS?view=diff&rev=123674&p1=httpd/httpd/branches/2.0.x/STATUS&r1=123673&p2=httpd/httpd/branches/2.0.x/STATUS&r2=123674 > == > --- httpd/httpd/branches/2.0.x/STATUS (original) > +++ httpd/httpd/branches/2.0.x/STATUS Wed Dec 29 12:39:46 2004 > @@ -260,6 +260,14 @@ >+1: stoddard, striker, jim >-1: brianp (we need a more robust solution than what's in 2.1 right > now), >jerenkrantz (should be fixed, but I don't have time to do this) > + trawick: Reviewing the thread in Dec '02, I don't see any > +proposal about more robust solutions once it was made clear > +that Connection: Close can't be used. If Justin is correct in > +his assertion that many servers don't handle TE: chunked, then the > +current solution is reasonable. If Justin is incorrect in that > +assertion, then something more robust is possible, such as > +buffering up to N bytes in hopes of reading the entire body, > +before deciding to send C-L or T-E: chunked. Alternate > recollections? Sleep helps. Consuming arbitrary amounts of memory to gather the entire request body in order to generate C-L could certainly be called non-robust ;) Any agreement to use the non-DOS-able and protocol-compliant implementation by default, and allow the C-L method to be enabled by a special setting? Even if somebody reworks the C-L method to be able to buffer on disk, that is wasted effort (and still a DOS concern) in many cases.
