[patch] mod_rewrite args + qsa
Hi,
Two mod_rewrite patches:
attached httpd-2.0.50-rewrite-args.patch will no longer omit $QUERY_STRINGs
of [P]-proxypassed requests after their rewriting and [QSA] possibly merging
a new QUERY_STRING.
.conf:
ServerName 10.10.145.100
RewriteEngine on
RewriteRule ^/ http://mms2.org/mms-off?operator=oskarmobil.cz [QSA,P]
Before patch:
213.220.235.217 - - [27/Aug/2004:11:45:59 +0200] GET
http://10.10.145.100/?message-id=8326039 HTTP/1.0 500 659
195.122.208.84 - - [27/Aug/2004:11:45:59 +0200] GET /mms-off HTTP/1.1 500 659
(2) init rewrite engine with requested uri /
(3) applying pattern '^/' to uri '/'
(2) rewrite '/' - 'http://mms2.org/mms-off?operator=t-mobile.cz'
(3) split uri=http://mms2.org/mms-off?operator=t-mobile.cz -
uri=http://mms2.org/mms-off, args=operator=t-mobile.czmessage-id=8326039
(2) forcing proxy-throughput with http://mms2.org/mms-off
(1) go-ahead with proxy request proxy:http://mms2.org/mms-off [OK]
After patch:
213.220.235.217 - - [27/Aug/2004:13:52:20 +0200] GET
http://10.10.145.100/?message-id=8326039 HTTP/1.0 200 221
195.122.208.84 - - [27/Aug/2004:13:52:20 +0200] GET
/mms-off?operator=oskarmobil.czmessage-id=8326039 HTTP/1.1 200 221
(2) init rewrite engine with requested uri /
(3) applying pattern '^/' to uri '/'
(2) rewrite '/' - 'http://mms2.org/mms-off?operator=oskarmobil.cz'
(3) split uri=http://mms2.org/mms-off?operator=oskarmobil.cz -
uri=http://mms2.org/mms-off, args=operator=oskarmobil.czmessage-id=8326039
(2) forcing proxy-throughput with http://mms2.org/mms-off
(1) go-ahead with proxy request
proxy:http://mms2.org/mms-off?operator=oskarmobil.czmessage-id=8326039 [OK]
The fix just follows the suggested /* see proxy_http:proxy_http_canon() */.
Patch applies both to httpd-2.0.50 and httpd-2.1 CVS.
The other patch - attached mod_rewrite-qsa.patch is just a fatal typo in the
current httpd-2.1 CVS.
Regards,
Lace
--
Jan Kratochvil; Captive: free r/w NTFS Filesystem; http://www.jankratochvil.net/
Index: modules/mappers/mod_rewrite.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_rewrite.c,v
retrieving revision 1.257
diff -u -p -r1.257 mod_rewrite.c
--- modules/mappers/mod_rewrite.c 17 May 2004 23:36:15 - 1.257
+++ modules/mappers/mod_rewrite.c 27 Aug 2004 11:27:01 -
@@ -4274,7 +4274,7 @@ static int hook_uri2file(request_rec *r)
r-path_info, NULL);
}
if (r-args != NULL
-r-uri == r-unparsed_uri) {
+r-uri != r-unparsed_uri) {
/* see proxy_http:proxy_http_canon() */
r-filename = apr_pstrcat(r-pool, r-filename,
?, r-args, NULL);
Index: modules/mappers/mod_rewrite.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_rewrite.c,v
retrieving revision 1.257
diff -u -p -r1.257 mod_rewrite.c
--- modules/mappers/mod_rewrite.c 17 May 2004 23:36:15 - 1.257
+++ modules/mappers/mod_rewrite.c 27 Aug 2004 11:27:01 -
@@ -3293,8 +3293,8 @@ static const char *cmd_rewriterule_setfl
case 'q':
case 'Q':
-if ( !strcasecmp(key, QSA)
-|| !strcasecmp(key, qsappend)) { /* qsappend */
+if ( !strcasecmp(key, SA)
+|| !strcasecmp(key, sappend)) { /* qsappend */
cfg-flags |= RULEFLAG_QSAPPEND;
}
else {
Re: [patch] mod_rewrite args + qsa
* Jan Kratochvil [EMAIL PROTECTED] wrote: Hi, Two mod_rewrite patches: attached httpd-2.0.50-rewrite-args.patch will no longer omit $QUERY_STRINGs of [P]-proxypassed requests after their rewriting and [QSA] possibly merging a new QUERY_STRING. I'm going to look deeper at this later this day. The other patch - attached mod_rewrite-qsa.patch is just a fatal typo in the current httpd-2.1 CVS. This obvious one is committed now. Thanks! nd -- Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine beiden Gefährten nicht zu zählen brauchte -- Karl May, Winnetou III Im Westen was neues: http://pub.perlig.de/books.html#apache2
1.3.32...
I'd like to propose a release of 1.3.32 sometime next week (say the 1st or 2nd of Sept). Please review HEAD. In particular, would those who were affected by the mod_dav/mod_frontpage patch in 1.3.31 please ensure that it is fixed as well as review the prelim patch. The solution tries to provide a generic solution to a lower level problem (making ap_set_keepalive capable of being called mutiple times per request with each call potentially bumping up the keepalives connection counter), but it does so using notes. I'd prefer something a bit more elegant but I have seen any other suggested patches (except for the original one which makes that safety external) and I've been so busy the last few weeks that I just threw that in as a quick and dirty solution. -- === 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
[PATCH] better method of ap_set_keepalive being multicall safe
Here is, I think, a better patch. The assumption is that it's only
in ap_set_keepalive that we set conn-keepalive to 1, so we
can overload that flag to not only represent Yes, keepalive
the connection but also as a we've called ap_set_keepalive
for this request already flag.
Index: src/main/http_protocol.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.336
diff -u -r1.336 http_protocol.c
--- src/main/http_protocol.c27 Aug 2004 23:44:41 - 1.336
+++ src/main/http_protocol.c28 Aug 2004 11:46:23 -
@@ -391,7 +391,6 @@
int wimpy = ap_find_token(r-pool,
ap_table_get(r-headers_out, Connection), close);
const char *conn = ap_table_get(r-headers_in, Connection);
-const char *herebefore = ap_table_get(r-notes, ap_set_keepalive-called);
/* The following convoluted conditional determines whether or not
* the current connection should remain persistent after this response
@@ -442,17 +441,19 @@
) {
int left = r-server-keep_alive_max - r-connection-keepalives;
-r-connection-keepalive = 1;
/*
* ap_set_keepalive could be called multiple times (eg: in
* ap_die() followed by ap_send_http_header()) during this
* one single request. To ensure that we don't incorrectly
* increment the keepalives counter for each call, we
-* use notes to store a state flag.
+* assume that only here do we set keepalive. So if keepalive
+* is already set to 1, we must have already been here and
+* we should not increment the keepalives counter since we
+* already done so for this request.
*/
- if (!herebefore) {
+if (r-connection-keepalive != 1) {
+r-connection-keepalive = 1;
r-connection-keepalives++;
-ap_table_setn(r-notes, ap_set_keepalive-called, 1);
}
/* If they sent a Keep-Alive token, send one back */
--
===
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
Smart filtering Module
I posted my proposed smart filter module a few days ago, in response a post here identifying a situation where it is relevant. I have now completed a first version of the accompanying manual page. I attach: mod_filter.xml mod_filter.xml.meta mod_filter.html Two images used to illustrate the module I've also uploaded the HTML to http://www.apache.org/~niq/ . I believe I have addressed the concerns raised when I mooted the idea of this some weeks ago: * Existing filters are binary-compatible with the new module * I've restored the filter_init handlers to the architecture * I've retained my proposal to enable dealing with aspects of the HTTP protocol on behalf of filter. However, the default is always for the filter harness to do nothing, and leave the filter provider (a content filter module) to deal with that as before. Working code and documentation (modulo bugs and TODOs) should help demonstrate the purpose and utility of the proposal, and move the discussion forward. I'd like to offer this as a contribution to the core httpd distribution, to be included as standard in 2.2. What is currently implemented is the basic architecture as described before. Configuration is fully dynamic, with my proposed set of configuration directives now implemented. Note that the module only applies to output filters and will only work with AP_FTYPE_RESOURCE or CONTENT_SET filters. I don't see a need for this functionality elsewhere (but I'm open to persuasion:-) The main TBD is an ap_filter... API interface for other modules to work actively with it. To implement that, I will need to merge the ap_filter_rec_t structure into the mod_filter_rec. This will be binary back-compatible (the new fields go on to the end of the ap_filter_rec_t), but will of course require commits to code outside the module, specifically util_filter. A second TODO is to enable mod_filter to run as a provider for itself. The purpose of this is to enable chaining of configuration rules beyond what we can already do by setting an environment variable with mod_rewrite and dispatching on an env= variable (example: insert DEFLATE depending on both Accept-Encoding request header and Content-Type response header. mod_rewrite can't do that because it runs too early to be sure to have the response headers). -- Nick Kew?xml version=1.0? !DOCTYPE modulesynopsis SYSTEM ../style/modulesynopsis.dtd ?xml-stylesheet type=text/xsl href=../style/manual.en.xsl? !-- $Revision: 1.18 $ -- !-- Copyright 2004 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- modulesynopsis metafile=mod_filter.xml.meta namemod_filter/name descriptionContext-sensitive smart filter configuration module/description statusExtension/status sourcefilemod_filter.c/sourcefile identifierfilter_module/identifier compatibilityApache 2.0 and higher/compatibility summary pThis module enables smart, context-sensitive configuration of output content filters. For example, apache can be configured to process different content-types through different filters, even when the content-type is not known in advance (e.g. in a proxy). /p /summary section id=smarttitleSmart Filtering/title pIn the traditional filtering model, filters are inserted unconditionally using directive module=coreAddOutputFilter/directive and family. Each filter then needs to determine whether to run, and there is little flexibility available for server admins to allow the chain to be configured dynamically./p pmod_filter by contrast gives server administrators a great deal of flexibility in configuring the filter chain. In fact, filters can be inserted based on any Request Header, Response Header or Environment Variable. This generalises the limited flexibility offered by directive module=coreAddOutputFilterByType/directive, and fixes it to work correctly with dynamic content, regardless of the content generator. The ability to dispatch based on Environment Variables offers the full flexibility of configuration with modulemod_rewrite/module to anyone who needs it./p /section section id=termstitleFilter Declarations, Providers and Chains/title img src=oldfilter.gif alt=/ pIn the traditional model, output filters are a simple chain from the content generator (handler) to the client. This works well provided the filter chain can be correctly configured, but presents problems when the filters need to be configured dynamically based on the
Re: Memory leak!?
On Fri, Aug 27, 2004 at 10:37:16PM +0200, Morten Due Jorgensen wrote: I have observed a memory leak problem in Apache 2 (starting with version fourty-something, but all the way up to the latest version 50). I am running it on Windows 2K (server) SP4. I have a rather simple home page, until recently it only had simple HTML pages, but now I have added some PHP-stuff and a PHPBB2. I saw the problem both before and after I added PHP, although it seems to be worse now than before. I have tried to EnableMMAP off, but the result is the same. What version of PHP? 4.3.8 has some memory leak fixes There's also a patch to fix a supposed memory leak in the Win32 MPM, no idea whether it's correct or not; see the comment from Alex Varju near the end of: http://issues.apache.org/bugzilla/show_bug.cgi?id=11427 joe
Re: Smart filtering Module
Nick Kew wrote: I posted my proposed smart filter module a few days ago, in response a post here identifying a situation where it is relevant. Ideally there should be one way of loading modules, not two - if it is practical to fix AddOutputFilter, then that should be done, otherwise if mod_filter works then I would suggest scrapping AddOutputFilter in favour of the mod_filter module. Regards, Graham --
Re: Smart filtering Module
On Sat, 28 Aug 2004, Graham Leggett wrote: Nick Kew wrote: I posted my proposed smart filter module a few days ago, in response a post here identifying a situation where it is relevant. Ideally there should be one way of loading modules, not two - if it is practical to fix AddOutputFilter, then that should be done, otherwise if mod_filter works then I would suggest scrapping AddOutputFilter in favour of the mod_filter module. Thanks for the comment. I agree in principle. In practice, there are a couple of issues to deal with. As it stands, mod_filter is only applicable to content filters, so protocol, connection and network filters have to be dealt with separately. That may be irrelevant: are there real-life examples of non-content filters being configured in httpd.conf? Secondly, removing existing directives will of course break configs for users. Do we want to do that without deprecating them first? Finally, what I've implemented is a 2.0 module. There's a fair bit of integration work to do in util_filter to eliminate duplication of functionality between the old and the new. And I expect breakage while that's work-in-progress. -- Nick Kew
Re: [PATCH] better method of ap_set_keepalive being multicall safe
I had used the same approach but just had it external. Putting it inside is a better idea. I still think it is dumb that this isn't called at a much earlier stage, but changing that is more likely to break stuff than this approach. -Rasmus On Sat, 28 Aug 2004, Jim Jagielski wrote: Here is, I think, a better patch. The assumption is that it's only in ap_set_keepalive that we set conn-keepalive to 1, so we can overload that flag to not only represent Yes, keepalive the connection but also as a we've called ap_set_keepalive for this request already flag.
Re: [patch] mod_rewrite args + qsa
* André Malo [EMAIL PROTECTED] wrote: * Jan Kratochvil [EMAIL PROTECTED] wrote: attached httpd-2.0.50-rewrite-args.patch will no longer omit $QUERY_STRINGs of [P]-proxypassed requests after their rewriting and [QSA] possibly merging a new QUERY_STRING. I'm going to look deeper at this later this day. Done. The patch looks fine, was added to 2.1 and proposed for backport into 2.0 and 1.3. Thanks again. nd -- Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine beiden Gefährten nicht zu zählen brauchte -- Karl May, Winnetou III Im Westen was neues: http://pub.perlig.de/books.html#apache2
[PATCH] Corrected some problems with mod_info.c
Bug report with patch file attached: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30919 mod_info seems to get all confused in cases like this: Location /x Order deny,allow Allow from all AuthType Basic AuthName Foo AuthUserFile .htpasswd LimitExcept PUT require valid-user /LimitExcept /Location The Location block is terminated with /LimitExcept and the configuration scan terminates prematurely. Changing the block to this makes it work: Location /x Order deny,allow Allow from all AuthType Basic AuthName Foo LimitExcept PUT require valid-user /LimitExcept AuthUserFile .htpasswd /Location This particularly affects viewing configuration directives in vhosts.
