Re: Migrate to git?
On Sat, Oct 05, 2019 at 04:09:34PM -0400, Jim Jagielski wrote: > Various PMCs have made their default/de-facto SCM git and have seen an > increase in contributions and contributors... > > Is this something the httpd project should consider? Especially w/ the > foundation officially supporting Github, it seems like time to have a > discussion about it, especially as we start thinking about the next 25 years > of this project :) > Hi, At W3C, all the Working Group spec as well as some developer work has moved on over to github. We use github's hooks API to connect actions on github repositories with our mailing lists and other aspects of the main server. Yes, git and github may have a steeper learning curve that svn, but people now seem satisfied with the current workflow. Yes, having this kind of work hosted at github has increased its visibility and getting unexpected external contributions. For the record, part of this change of system required migrating CVS repositories from our servers at W3C to github, while preserving all the history of commits and names of commiteers, using readily available tools. There were some incompatibilities between CVS unmerged branches, though, and we had to take decisions in that case. This may not be the case for SVN. Another important reason that pushed for this migration is that CVS clients are becoming less available across platforms. I'm not sure if that's the same situation for SVN, although I see there are still recent releases of it. It helps it's hosted at ASF. For simplicity, from here one I will use "apache" to refer to the httpd server. I think that one step for migrating apache to github would require your writing down a list of things you need from a DRCS and then working on how to map them to github. One thing that I find important is that you evaluate how you're going to handle contributions, or, in git parlance, merge requests (MR). These are public visible in the repository. Having too many hanging out without closure doesn't speak well for a project. I talk of this from experience of seeing that bug reportss and proposed bug fixes are quickly fixed and integrated into apache (Thanks Yann!), however, proposal for extensions of existing modules, even when developed in consultation with the list, just go dormant and require multiple prodding today and even like that, the hit ratio is really low in my opinion. After I while this just demotivated me from continuing proposing them to this list and just stick to the ocassional bug report / patches.. See for example the latest one, dating from 2015 [1]. When this happens in github, the result may be that someone forks your project and makes a new one out of it. Another thing from the migration that I think you should consider is what you're going to do with your existing bugzilla content. Are you going to keep using it or use the github issues for that? Are you going to migrate open issues there? How about the links in reports pointing to your svn repository? Finally, as much as migrating to github can be interesting, you must also consider not being tied to github in case any future policy changes don't please you. You must be prepared to be able to migrate to another system if needed and see how much of the github environment can follow you. Can the issues follow you? How about the discussions in github? etc. What parts of github are you going to use, which ones disable (and can they be disabled?). Other alternatives for github are gitlab. You can install an instance of gitlab locally or use their repository. Upon the announcement of MS buying github, some projects migrated to gitlab. If it may help, I can put you in contact with the people in our team that can describe more in detail how W3C is using github today, the hooks, CI, how we backup it, and the advantages and limitations we have found so far. Hope this feedback helps, --josé [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=58025
Re: PHP test cases
On Tue, Nov 21, 2017 at 04:31:57PM -0600, Daniel Ruggeri wrote: > > Also, t/php/getlastmod.t fails because of a warning[2] unless php.ini > has been set to explicitly declare a timezone (unsure of which version > PHP made this a warning). Should we modify our php script or modify the > comparison to be a match that includes the month? My workaround was to > create a php.ini on the fly but we ought to handle this better in the code. See: http://php.net/manual/en/function.date-default-timezone-set.php You need to set that value, either thru that function or thru php.ini. Are you invoking the testsuite from php cli? Hope this helps. --josé
Re: modules.apache.org is down
On Wed, Mar 15, 2017 at 05:36:47PM +0100, Jose Kahan wrote: > > It's been a couple of months (if not more) that the 3rd party > module repo is unavailable. the last discussion I saw about > this site dates from Nov 2016, where people were talking about > moderation, spambots, and making a new system. I meant Nov. 2015. --josé
modules.apache.org is down
Hi, It's been a couple of months (if not more) that the 3rd party module repo is unavailable. the last discussion I saw about this site dates from Nov 2016, where people were talking about moderation, spambots, and making a new system. Are you planning to bring it back online? Otherwise, it would be better to remove the link that points to it from this page: https://modules.apache.org/ I hope it comes back! Cheers, --josé
mod_index : missing Content-Location header
Hi, Best wishes for 2016! Does anyone know why mod_dir doesn't generate a Content-Location header when a URI ending in "/" is requested? This is a behavior that is common in 2.2 and 2.4. For some publishing tools, it's useful to know what's the actual URI that's mapped to "/" thru DirectoryIndex. I can contribute time to propose a patch that does this. I can either add this as an in-built feature to mod_dir with configuration options to disable it or as an optional hook tha's called once there's a positive match for a DirectoryIndex entry. Any comments? Thanks! -jose
Re: Weird interaction between mod_dir and [P] rewrites
Eric, On Tue, Nov 24, 2015 at 01:37:09PM -0500, Eric Covener wrote: > Tried DirectoryCheckHandler? It's a 2.2-vs-2.4 difference discovered a > little too late to change by default. Thank you very much. That fixed my issue. I wonder if it would be interesting to add a note about this change in behavior and the directive in [1]. Thank you again for your promt reply. Cheers, -jose [1] http://httpd.apache.org/docs/2.4/upgrading.html
Weird interaction between mod_dir and [P] rewrites
Hi, This is something that has changed in 2.4 compared to 2.2. When I follow the simple scenario (attached file) in a fresh install of apache, mod_dir is affecting the first value of DirectoryIndex to my request before it is being proxied. In 2.2, I was used to browse "https:/example,com/foo/" and have this being proxied to a backend as "https://example2.com/bar/";. But now in 2.4.7, mod_dir is first converting "/foo/" to "/foo/index.html" and then sending the proxy request as "/bar/index.html". Do you know if this is an intended feature or a bug? I would expect the backend, and not the frontend, to decide what it wants to add to a url ending by "/". The code in mod_dir has changed and there's a section with a comment saying that it steps aside when it detects it is inside a mod_rewrite fixup. It seems to be missing a provision for proxy requests. rbowen helped me test this against 2.4.17/fedora. I tested it against 2.4.10/debian jessie with the same result. Thanks! Cheers. -jose Scenario for mod_dir and mod_rewrite bug Tested against 2.4.17 in a fresh fedora install (Thanks rbowen!) I have this setup /foo/.htaccess /bar/echo.php Server runs in localhost. 1. In your apache config, make sure you have the DirectoryIndex directive e.g. DirectoryIndex index.html 2. Put the following php script under /bar/echo.php Its goal is to echo the request URI. You can do it with another script if you want: [[ $ cat echo.php ]] 3. Put this .htaccess under /foo/.htaccess [[ $ cat .htaccess RewriteEngine on RewriteBase /foo RewriteRule ^(.*)$ http://localhost/bar/echo.php/$1 [P,L] ]] 4. Try the test GET -Se http://localhost/foo/ If you get back: Requested: ...echo.php/index.html # index.html is the first value of my DirectoryIndex directive You see the bug, mod_dir added the first value of DirectoryIndex before doing the proxy request.
Re: patch to mod_authz_dbd to handle query parameters
Hi, Not having heard back since submitting this enhancement, I decided to put it on github to share it with other people who may be interested by it [1]. I integrated the changes from [2] and used 2.4.17 as the "base version". My original submission is [3]. Feel free to contact me if you are interested to integrate this into apache and require further changes. -jose [1] https://github.com/jkbzh/apache2_mod_authz_dbd [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=57868 [3] https://bz.apache.org/bugzilla/show_bug.cgi?id=58025
Re: Re: patch to mod_authz_dbd to handle query parameters
Argh, I forgot to include the link to the message! Sorry about that. http://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3c20150428165148.ga17...@kiribati.inrialpes.fr%3E -jk
Re: patch to mod_authz_dbd to handle query parameters
Hi! A gentle reminder that I had submitted this patch and would like to know if someone has had time to review it and/or would like further modifications. Should I add a bugzilla entry so that it doesn't fall under the radar? Thanks! Kudos. -jk
patch to mod_authz_dbd to handle query parameters
Hi,
I realized that my last message was missing a part of the
info I had prepared. I'm resending it with a new subject
to make it clearer what it is.
I slightly revised the patch in that it had a unused variable.
I don't know why -Wc-Wunused didn't work with apxs2.
To compile and install the patch:
apxs2 -i -a -c mod_authz_dbd.c
Looking forward to your feedback or RFE. More details here below.
I'm also opening a bug report for the dbd issue I found (and fixed
in this patch).
Cheers,
-jose
DETAILED REPORT
Work done:
- As discussed earlier in this thread, new require dbd-query directive
for supporting query parameters. If the query returns at least one
row, we consider that access is granted.
- It's now possible to use query parameters for dbd-login and
dbd-logout. If no parameter is given, the default value is
%{REMOTE-USER} to keep backwards compatibility.
- While testing the changes for dbd-login, a server misconfiguration
revealed a SIGSEV. If the dbd handle preparation fails due to a
misconfiguration of the database server or the access rights to the
table, the server logs something along these lines:
AH00632: failed to prepare SQL statements: UPDATE command denied to
user 'foo'@'exampleorg' for table 'bar'
As a consequence, the call to dbd_handle(r) returns NULL. However,
in mod_authz_dbd, there was no control for the value of dbd before
its being used in both authz_dbd_login() and authzdbd_group():
ap_dbd_t *dbd = dbd_handle(r);
...
query = apr_hash_get(dbd->prepared, <--- SIGSEV
I added a check to protect against this case.
Open issues:
- I wanted to control that the number of bind arguments correspond to
those in the prepared request. However this value is not visible in
apr_dbd_prepared_t *query. Looking at the code in apr_dbd.c, I see
that even though the number of bind arguments are being passed to
apr_dbd_pselect() and apr_dbd_pquery() in nargs, this argument is
discarded before calling the implementation of those functions in
the driver.
At least in the mysql driver, there is no further check that there
is an equivalence between the bind and prepared statement
arguments. In both cases there is just a call to
mysql_stmt_bind_param(statement->stmt, bind);
which expects bind to have the correct number of arguments. I
checked the sqlite3 driver and it has the same issue.
If bind has more arguments, there is no issue. If there is less, we
risk a SIGSEV or unexpected behavior.
To avoid this issue, I wanted to control the number of arguments
when parsing the configuration file and show a configuration error
when necessary. However, as the prepared query goes into opaque
driver implementations, I don't have access to its nargs value. Are
there any ideas on how to get this info? The only hack I could
think of is counting the number of % inside the prepared query and
making sure that we have the corresponding number of bind arguments.
- Would it be worth it to connect this module to mod_socache.c?
Other questions:
- In function dbd_parse_config, I was unable to decide whether it
would be ok to use cmd->temp_pool instead of cmd->pool in my call to
ap_getword_white()
- I am using ap_expr_parse_cmd() on each argument of the require
dbd-query, dbd-login, and dbd-logout directives. I think this is
akin to building an expression tree for each argument. Is there a
more efficient way to do so?
Index: /tmp/httpd-trunk/modules/aaa/mod_authz_dbd.c
===
--- /tmp/httpd-trunk/modules/aaa/mod_authz_dbd.c (revision 1676575)
+++ /tmp/httpd-trunk/modules/aaa/mod_authz_dbd.c (working copy)
@@ -109,7 +109,45 @@
{NULL}
};
+static int evaluate_query_parameters(request_rec *r,
+ const apr_array_header_t *parsed_require_args,
+ const void **query_parameters)
+{
+int i;
+apr_array_header_t *qp;
+
+const ap_expr_info_t *expr = NULL;
+const char *parameter;
+
+const char *err = NULL;
+
+/* evaluate the query parameters in parsed_require_args */
+qp = apr_array_make(r->pool,
+ parsed_require_args->nelts,
+ sizeof (char *));
+
+for (i = 0; i < parsed_require_args->nelts; i++) {
+
+expr = ((const ap_expr_info_t **)parsed_require_args->elts)[i];
+parameter = ap_expr_str_exec(r, expr, &err);
+
+if (err) {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO()
+ "authz_dbd in evaluate query_parameters: Can't "
+ "evaluate require expression: %s", err);
+return HTTP_INTERNAL_SERVER_ERROR;
+}
+
+*(const char **)apr_array_push(qp) = parameter;
+}
+
+*query_parameters = (void *)qp;
+
+return OK;
+}
+
static int authz_dbd_login(request_rec *r, authz_dbd_cfg *cfg
Re: Extending mod_authz_dbd
Hi Graham,
Here's a first patch that adds the functionality that you suggested.
> Require dbd-login %{REQUEST_URI} %{REQUEST_METHOD} %{REMOTE_USER}
> AuthzDBDQuery "UPDATE authn SET uri = %s, method = %s WHERE user = %s”
>
> Require dbd-logout %{TIME} %{REMOTE_USER}
> AuthzDBDQuery "UPDATE authn SET logout_time = %s WHERE user = %s”
>
> To be backwards compatible, "Require dbd-login” on it’s own would imply
> "Require dbd-login %{REMOTER_USER}”.
>
> One possible approach to support completely generic queries might be as
> follows:
>
> Require dbd-query %{REQUEST_URI} %{REMOTE_USER}
> AuthzDBDQuery “SELECT count(user) FROM authn WHERE uri=%s AND user = %s”
Although I developed and tested this against the 2.4.10 source
tree (the latest debian jessie version), I checked and this
module as well as mod_dbd.c have not changed since then neither
in the latest 2.4.x nor in trunk. I don't think there will be
an issue running it there. Installing that environment over the
default debian one could be a hazzle for me that I'd prefer
to avoid , but that I could do if needed.
Here below are some development notes.
Please keep me update if I can contribute something else to this
patch, that it be documentation or further changes. I understand
there's no engagement to accept this code from you. We can chat
on irc too if needed.
Cheers,
-jose
Open issues:
- I wanted to control that the number of bind arguments correspond to
those in the prepared request. However this value is not visible in
apr_dbd_prepared_t *query. Looking at the code in apr_dbd.c, I see
that even though the number of bind arguments are being passed to
apr_dbd_pselect() and apr_dbd_pquery() in nargs, this argument is
discarded before calling the implementation of those functions in
the driver.
At least in the mysql driver, there is no further check that there
is an equivalence between the bind and prepared statement
arguments. In both cases there is just a call to
mysql_stmt_bind_param(statement->stmt, bind);
which expects bind to have the correct number of arguments. I
checked the sqlite3 driver and it has the same issue.
If bind has more arguments, there is no issue. If there is less, we
risk a SIGSEV or unexpected behavior.
To avoid this issue, I wanted to control the number of arguments
when parsing the configuration file and show a configuration error
when necessary. However, as the prepared query goes into opaque
driver implementations, I don't have access to its nargs value. Are
there any ideas on how to get this info? The only hack I could
think of is counting the number of % inside the prepared query and
making sure that we have the corresponding number of bind arguments.
- Would it be worth it to connect this module to mod_socache.c?
Other questions:
- In function dbd_parse_config, I was unable to decide whether it
would be ok to use cmd->temp_pool instead of cmd->pool in my call to
ap_getword_white()
- I am using ap_expr_parse_cmd() on each argument of the require
dbd-query, dbd-login, and dbd-logout directives. I think this is
akin to building an expression tree for each argument. Is there a
more efficient way to do so?
Index: mod_authz_dbd.c
===
--- mod_authz_dbd.c (revision 1675706)
+++ mod_authz_dbd.c (working copy)
@@ -109,7 +109,45 @@
{NULL}
};
+static int evaluate_query_parameters(request_rec *r,
+ const apr_array_header_t *parsed_require_args,
+ const void **query_parameters)
+{
+int i;
+apr_array_header_t *qp;
+
+const ap_expr_info_t *expr = NULL;
+const char *parameter;
+
+const char *err = NULL;
+
+/* evaluate the query parameters in parsed_require_args */
+qp = apr_array_make(r->pool,
+ parsed_require_args->nelts,
+ sizeof (char *));
+
+for (i = 0; i < parsed_require_args->nelts; i++) {
+
+expr = ((const ap_expr_info_t **)parsed_require_args->elts)[i];
+parameter = ap_expr_str_exec(r, expr, &err);
+
+if (err) {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO()
+ "authz_dbd in evaluate query_parameters: Can't "
+ "evaluate require expression: %s", err);
+return HTTP_INTERNAL_SERVER_ERROR;
+}
+
+*(const char **)apr_array_push(qp) = parameter;
+}
+
+*query_parameters = (void *)qp;
+
+return OK;
+}
+
static int authz_dbd_login(request_rec *r, authz_dbd_cfg *cfg,
+ const void *parsed_require_args,
const char *action)
{
int rv;
@@ -120,12 +158,18 @@
apr_dbd_prepared_t *query;
apr_dbd_results_t *res = NULL;
apr_dbd_row_t *row = NULL;
+apr_array_header_t *query_parameters;
if (cfg->query == NULL) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01
Re: Extending mod_authz_dbd
Hello Graham,
Thanks for your feedback. It all makes sense to me.
Following your reasoning, the only directive that will have i
to stay as is for backwards compatibility will be require
dbd-group, as it expects either no parameter or the value
the query will return.
I had initially thought of only using one directive and
extracting the variables from the AuthzDBDQuery arguments,
substituting them for %s and then preparing the request. Your
proposal is much simpler so I'll go with it.
I'm already looking at the code. Will keep you (and the list)
updated as soon as I have something to share.
Regards,
-jose
On Wed, Apr 15, 2015 at 11:17:04AM +0200, Graham Leggett wrote:
>
> The limitations we’d have to work with is that all the queries are prepared
> statements, and are reused for multiple requests. At the same time any query
> that is interpreted purely as a string would need to be protected against SQL
> injection.
> Require dbd-login %{REQUEST_URI} %{REQUEST_METHOD} %{REMOTE_USER}
> AuthzDBDQuery "UPDATE authn SET uri = %s, method = %s WHERE user = %s”
>
> Require dbd-logout %{TIME} %{REMOTE_USER}
> AuthzDBDQuery "UPDATE authn SET logout_time = %s WHERE user = %s”
>
> To be backwards compatible, "Require dbd-login” on it’s own would imply
> "Require dbd-login %{REMOTER_USER}”.
>
> One possible approach to support completely generic queries might be as
> follows:
>
> Require dbd-query %{REQUEST_URI} %{REMOTE_USER}
> AuthzDBDQuery “SELECT count(user) FROM authn WHERE uri=%s AND user = %s”
>
> The bit above where you’d limit the requests to GET or POST you’d probably do
> with Limit or LimitExcept.
Extending mod_authz_dbd
Hi,
We're preparing the migration to apache 2.4 and we're happy
to see that many features now available allow us to put to
rest most of our custom developed modules.
Looking at mod_authz_dbd, we would like to make a request
against a dbase passing different parameters (REQUEST_URI,
REQUEST_METHOD, REMOTE_USER, ...) to support a fine-grained
ACL mechanism. However, this module doesn't seem to support
resolving those variables when preparing the SQL query.
Looking at the code, the only one that seems supported is
a hard-coded r->user in authz_dbd_group_query:
rv = apr_dbd_pvselect(dbd->driver, r->pool, dbd->handle, &res,
query, 0, r->user, NULL);
Is there any historical reason for this? Would you be interested
in our contributing time to extend this module to support more
generic queries such as (invented query)
require sql-query "SELECT * FROM foo WHERE user=${REMOTE_USER}
AND uri=${REQUEST_URI} AND ${REQUEST_METHOD} in
('GET', 'POST')"
While browsing for information regarding this point, I only
found people asking if this was possible, but no hints if there
had been (or will be) plans to do this.
The defunct mod_auth_mysql used to propose something similar. i
This module is not officially maintained anymore.
A possible point of confusion in the module's doc [1] is the
phrase saying
"Since v2.4.8, expressions are supported within the DBD
require directives."
while the requires in the paragraphs below can't support expressions,
as far as I can tell. I may be missing something.
Please keep me update if you'd be interested in this generic
contribution, which we would be happy to make, rather than forking
and maintaining a derived and non-generic patch to this module.
If you're interested, I'd appreciate some feedback on how the feature
should look like so that it's designed that way before coding it,
rather than coding, proposing the contribution and getting feedback
it wasn't what x had in mind.
Of course, it's understood that your showing interest for this doesn't
mean you will end up accepting the contribution.
Thanks and KUDOS! Apache 2.4 rocks!
-jose
Re: Misleading example in Apache 2 doc (fix)
Hi André, > language\s*=\s*([^;,\s]+) Your expression works well and is simpler than mine. +1 to update the doc with it instead of my proposal. Thanks :) -jose
Misleading example in Apache 2 doc (fix)
I didn't do my homework completely. According to RFC 2910, Cookie tokens may be separated by white space. The correct regular expression is: [[ SetEnvIf Cookie "language\s*=\s*([a-z|A-Z][a-z|A-Z|-]+)" prefer-language=$1 ]] Thanks! -jose
Misleading example in Apache 2 doc
! I'm not sure if I should mail this here or open a new bugzilla report. Please advice. The Content Negotiation doc is using a misleading example in this section: http://httpd.apache.org/docs/2.2/content-negotiation.html#better [[ Example SetEnvIf Cookie "language=(.+)" prefer-language=$1 Header append Vary cookie ]] That regular expression won't work if the cookie has other attributes in addition to the language one. One of our users got caught by it. A quick search on the web shows that many people have had this problem too. Here's a correct regular expression that will return the language attribute value, regardless of the contents of the cookie: [[ SetEnvIf Cookie "language=([a-z|A-Z][a-z|A-Z|-]+)" prefer-language=$1 ]] The expression looks bigger because it takes into account not only strings like "en", but also "zh-hans". I added upper and lower case as cookies are case insensitive and I'm not sure if Apache converts cookies to lower-case at some point. If it's always lower case, we can simplify the regular expression to: [[ SetEnvIf Cookie "language=([a-z][a-z|-]+)" prefer-language=$1 ]] Could you update the example in the doc accordingly? Thanks! -jose
Gentle reminder of outstanding contributed patches
Hi folks, Per the patch submission suggestion # 1: [[ Be persistent but polite. Post to the developers list pointing out your patch and why you feel it is important. Feel free to do this about once a week and continue until you get a response. Just be sure to be polite about it, since the developers are unlikely to respond to rude messages. ]] Here's a gentle reminder and summary of myoutstanding (as in non-committed) patches (bug fixes, test procedures) that I've submitted over the last couple of months. If it may be easier for you, I published a page giving the status and links to all of these patches on the apache bugzilla server:. http://www.w3.org/2007/10/osc As always, feel free to ask any question or send feedback. N.B. We have applied all of these patches to our production servers, which are now 2.2.8. All of these patches were still needed. I only had to change one to work against 2.2.8. The rest of the patches work without changes on 2.2.8. If it may be easier for you, I published a page giving links to all of these patches inside bugzilla. http://www.w3.org/2007/10/osc Best regards, -jose Patch: Restoring location walking in subrequests * Summary: Apache is not using custom content-types when accessing content-negotiated resources * Apache bugzilla entry: 41960[5] * Bug report submitted: Mar 2007 * Patch against trunk and 2.2.6 and 2.2.8 submitted: 6, 10 August 2007, 31 Jan 2008 [6] * Status: patch committed to trunk on 13 Sep 2007; not yet available in released server. Test: location walking in subrequests * Summary: Checks that directives stored in .htaccess files as well as , , and sections is taken into account when handling subrequests. Complements PR 41960. * Apache bugzilla entry: 43679[8] * Patch against trunk submitted: 01-Oct-2007[9] (rev. version to apache-dev[10]). Resubmitted: 23-Oct-2007 (bugzilla) * Status: waiting for action from Apache-dev guys Patch: mod_negotiation is not passing query strings and path info when using typemaps * Summary: completes the work started on by PR 33112. * Apache bugzilla entry: 43550[12] * Bug report submitted: 4 Oct 2007 * Patch against trunk and 2.2.6 submitted: 11-Oct-2007[13] (rev. version) * Status: waiting for action from apache-dev guys Patch: Removing dependency between mod_speling and the AcceptPathInfo directive * Summary: PR 21059 added this dependency. It is not needed anymore and has degraded the use of mod_speling because it introduces a hard dependency with the AcceptPathInfo directive. * Apache bugzilla entry: 43562[18] * Bug report submitted: 5 Oct 2007 * Patch against trunk and 2.2.6 submitted: 5 Oct 2007[19] * Status: waiting for action from apache-dev guys [5] http://issues.apache.org/bugzilla/show_bug.cgi?id=41960 [6] http://issues.apache.org/bugzilla/show_bug.cgi?id=41960 [8] http://issues.apache.org/bugzilla/show_bug.cgi?id=43679 [9] http://issues.apache.org/bugzilla/show_bug.cgi?id=43679 [12] http://issues.apache.org/bugzilla/show_bug.cgi?id=43550 [13] http://issues.apache.org/bugzilla/show_bug.cgi?id=43550 [18] http://issues.apache.org/bugzilla/show_bug.cgi?id=43562 [19] http://issues.apache.org/bugzilla/show_bug.cgi?id=43562
Gentle reminder of outstanding contributed patches
Hi folks, Per the patch submission suggestion # 1: [[ Be persistent but polite. Post to the developers list pointing out your patch and why you feel it is important. Feel free to do this about once a week and continue until you get a response. Just be sure to be polite about it, since the developers are unlikely to respond to rude messages. ]] Here's a gentle reminder and summary of myoutstanding (as in non-committed) patches (bug fixes, test procedures) that I've submitted over the last ocuple of weeks. As always, feel free to ask any question or send feedback. N.B. We have applied all of these patches to our production servers. Best regards, -jose Test: location walking in subrequests PR 43679[6] * Summary: Checks that directives stored in .htaccess files as well as , , and sections is taken into account when handling subrequests. Complements PR 41960. * Apache bugzilla entry: PR 43679[6] * Patch against trunk submitted: 01-Oct-2007[7] (rev. version to apache-dev[8]). Resubmitted: 23-Oct-2007 (bugzilla) * Status: waiting for action from Apache-dev guys Patch: mod_negotiation is not passing query strings and path info when using typemaps PR 43550[9] * Summary: completes the work started on by PR 33112. * Apache bugzilla entry: PR 43550[9] * Bug report submitted: 4 Oc 2007 * Patch against trunk and 2.2.6 submitted: 11-Oct-2007[10] (rev. version) * Status: waiting for action from apache-dev guys Test: passing query strings when using typemaps PR 43550[11] * Summary checks tha query strings are passed correctly when using typemaps * Apache bugzilla entry: PR 43550[11] * Patch against trunk submitted: 11-Oct-2007[12] (rev. version) * Status: waiting for action from Apache-dev guys Patch: Removing dependency between mod_speling and the AcceptPathInfo directive PR 43562[13] * Summary: PR 21059 added this dependency. It is not needed anymore and has degraded the use of mod_speling because it introduces a hard dependency with the AcceptPathInfo directive. * Apache bugzilla entry: PR 43562[13] * Bug report submitted: 5 Oct 2007 * Patch against trunk and 2.2.6 submitted: 5 Oct 2007[14] * Status: waiting for action from apache-dev guys Patch: Fixing invalid XHTML markup in mod_autoindex PR 43649[15] * Summary: XHTML version of autoindex is missing the HTML namespace * Apache bugzilla entry: PR 43649[15] * Bug report submitted: 18 Oct 2007 * Patch against trunk and 2.2.6 submitted: 18 Oct 2007[16] * Status: waiting for action from apache-dev guys -- List of References [6] http://issues.apache.org/bugzilla/show_bug.cgi?id=43679 [7] http://issues.apache.org/bugzilla/show_bug.cgi?id=43679 [8] http://mail-archives.apache.org/mod_mbox/httpd-dev/200710.mbox/[EMAIL PROTECTED] [9] http://issues.apache.org/bugzilla/show_bug.cgi?id=43550 [10] http://issues.apache.org/bugzilla/show_bug.cgi?id=43550 [11] http://issues.apache.org/bugzilla/show_bug.cgi?id=43550 [12] http://issues.apache.org/bugzilla/show_bug.cgi?id=43550 [13] http://issues.apache.org/bugzilla/show_bug.cgi?id=43562 [14] http://issues.apache.org/bugzilla/show_bug.cgi?id=43562 [15] http://issues.apache.org/bugzilla/show_bug.cgi?id=43649 [16] http://issues.apache.org/bugzilla/show_bug.cgi?id=43649
Re: As we contemplate what to fix, and how to roll out 2.4 and 3.0
If it could help your PR effort, maybe you could have some kind of online testimonial or survey page of companies or big sites that have moved to Apache 2.2, stating how much time it took them to migrate to it from the previous server version, how much effort it took to migrate their propietary modules, and what gains in performance, stable server behavior they have observed. I'd also include a last section stating if they aborted their move, to state the reasons why. The above survey would let users see, by consulting their peers opinion, the benefits (and possible drawbacks) of moving to Apache 2.2. If there's such a page, we (W3C), can fill in an entry re: our migration to Apache 2.2. Cheers, -jose
Re: Jose's recent location test/failures
Hello, Here's my second take at submitting these tests. Following Bill's comments, I did some changes to remove the ambiguity. These tests check that the directives inside , sections as well as .htaccess are taken into account when processing internal subrequests. The test case consists in using AddCharset to add a bogus charset in the configuration and using conneg to trigger a subrequest. e.g., Options +MultiViews AddCharset bogus .bc Although there are six tests, only test four fails when PR 41960 is not applied. I added the extra five just to make sure the flaw won't appear in the other sections. You will find here attached the subrequests.t test file as well as a tgz archive with the tests. Before running the tests, you need to patch extra.conf.in using the included extra.conf.in.patch diff file. This is a diff from svn trunk. Feel free to request further changes. -jose subrequests.t Description: Troff document subrequests-20061001.tgz Description: GNU Unix tar archive
Re: svn commit: r579664 - in /httpd/httpd/trunk: CHANGES server/request.c
Hi nd, On Wed, Sep 26, 2007 at 08:40:08PM +0200, Andr?? Malo wrote: > > > > URL: http://svn.apache.org/viewvc?rev=579664&view=rev > > Log: > > Reinstate location walk for subrequests > > PR 41960 (Jose Kahan) > > I don't see how the comment matches the patch. We always had location walks > for subrequests, but not for *file* subrequests. How does that make sense? > > I'm sure this will break a lot of stuff and assumptions. mod_cern_meta comes > into mind plus everywhere, where you really want to sub request for a file > and not a location (and don't even have a good location to map to) If it may assure you... The comments of my patch just describe the behavior I saw. There may be better appropriate language for it. I have test cases that show how location walk wasn't working anymore and how the patch fixes it. I've just sent one such message to the list. I think that best thing would be for you to try the patch and test out the scenarios you think it will break down and report back to the list if that is the case? Or point out places in the code that will be at risk? For the record, the W3C production web servers are using this patch since some time ago and we haven't experienced any i weird behavior. Of course, this doesn't exclude problems with server configuration options that we don't use. Cheers, -jose
Re: Jose's recent location test/failures
Hello Bill, Thanks for your reply. On Wed, Sep 26, 2007 at 02:05:26PM -0500, William A. Rowe, Jr. wrote: > > I believe the mistaken assumption is that charset can be used in this way. > AddCharset should be used in this case. > > If no AddCharset is applied, AddDefaultCharset takes over. > > http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addcharset > http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset > > Is that the origin of this observed 'flaw'? Indeed, the text of my test may be ambiguous. The flaw that I noticed is related to subrequests not taking into account what is inside the different , and .htaccess sections. I made a quick modification to my tests using AddCharset: [[ Options +MultiViews AddCharset something .mt ]] Elsewhere, in the configuration file I have AddDefaultCharset iso-8859-1 AddType text/html html htm I also have a file named test.html.mt in the conneg-test directory. --- Doing the tests with Apache 2.2.6: HEAD http://localhost/conneg-test/test.html.mt returns Content-Type: text/html; charset=something whereas HEAD http://localhost/conneg-test/test.html HEAD http://localhost/conneg-test/test both return Content-Type: text/html; charset=iso-8859-1 Thus showing that the specific AddCharset is not being taken into account in subrequests. I think this would be the case for any other directive in those sections. This is fixed by my patch (that was committed today, many thanks :). If these tests are less ambiguous in this new form, I can resubmit them. -jose
[mod_spelling] misuse of AcceptPathInfo?
Hi,
Since Apache 2.2, one has to turn on AcceptPathInfo
in order to correct directory mispelings:
CheckSpelling On
AcceptPathInfo On
This is because mod_speling has the following code:
[[
/* we default to reject path info (same as core handler) */
if ((r->used_path_info != AP_REQ_ACCEPT_PATH_INFO) &&
r->path_info && *r->path_info) {
return DECLINED;
}
]]
Having to turn on the AcceptPathInfo to be able to use
mod_speling seems wrong. When Apache is parsing a URI and
doesn't find an equivalent filename, it is storing the
"extra" information into r->path_info. However, unless
AcceptPathInfo is turned on, mod_speling won't even try
to fix the spelling.
For example, the following URI is a valid one:
http://www.w3.org/TR/2004/WD-ccxml-20040430/
If AcceptPathInfo has a value different than On, we will
get a 404 status on the following (TR spelled as tr):
http://www.w3.org/tr/2004/WD-ccxml-20040430/
thus defeating the benefits of using of mod_speling.
On the other hand, if you turn on AcceptPathInfo, you
get mod_speling to work. On the other hand, you
are accepting PathInfo even if you don't want, and even
if it's a bogus. Any time a file foo.ext exists, requests for
foo/* are served with 200 OK status. e.g.,
http://www.w3.org/MarkUp/Overview/asdf
http://www.w3.org/MarkUp/Overview.html/asdf
Moreover, this breaks the browser-side resolution of
relative links.
Our stats show that Apache 1.x didn't accept bogus PathInfo. The
above URIs would return a 404 status, just as if we had
never enabled AcceptPathInfo in 2.2.
Is there any special reason as to why mod_speling is running
conditional to the value of AcceptPathInfo? I don't see
any benefit to it as you have to enable AcceptPathInfo for your
server and you get side effects.
Does it make sense to remove that check from mod_speling?
Thanks,
-jose
[bug + naive patch] mod_negotiation + query parameters
Hi,
This is a bug similar to PR 33112 which was fixed in 2.2.6.
Query strings are not being passed along when mod_negotiation
combines multiviews with typemap processing.
The guilty party is the call to
ap_internal_fast_redirect(sub_req, r)
in mod_negotiation.c:handle_multi() which discards the
previously parsed args and path_info. That info is
not regenerated again. I'm including a very naive patch
against 2.2.6 that fixes this. I'm sure there is a
better way to fix it, but need more of your guidance
to achieve it in an optimal way.
Here's a test scenario to show this bug. Please adjust accordingly
to your server setup. I assume the use of php
for printing out the query parameters; you could use
perl or a shell script too):
1. In a directory, put the three files that I've attached:
test.html, test.php, test.var
2. query the server for test.php?q=3
http://localhost/test.php?q=3
==> you'll see that the query parameters are correctly
passed to the script.
3. query the server for test?q=3
http://localhost/test?q=3
==> in this case, the query parameters have been discarded
by mod_negotiation's call to
ap_internal_fast_redirect inside handle_multi().
You'll see that my naive solution is to make a backup copy of
args and path_info, if they existed, before the call to
ap_internal_fast_redirect(), and then restoring them. This
effectively solves the bug. I don't know if there's a better
way to do this.
Thanks,
-jose
Title: type map test
you shouldn't see this html file
URI: test
URI: test.php
Content-type: text/html;qs=1.0
URI: test.html
Content-type: text/html;qs=0.01
test.php
Description: application/httpd-php
--- mod_negotiation.c.orig 2007-09-25 15:47:37.0 +0200
+++ mod_negotiation.c 2007-09-25 15:47:45.0 +0200
@@ -3132,7 +3132,28 @@
}
/* now do a "fast redirect" ... promotes the sub_req into the main req */
-ap_internal_fast_redirect(sub_req, r);
+{
+ /* save the previous parsed args and path_info */
+ char *args;
+ char *path_info;
+
+ if (r->args) {
+ args = apr_pstrdup(r->pool, r->args);
+ } else {
+ args = NULL;
+ }
+
+ if (r->path_info) {
+ r->path_info = apr_pstrdup(r->pool, r->path_info);
+ } else {
+ path_info = NULL;
+ }
+ ap_internal_fast_redirect(sub_req, r);
+
+ /* restore the parsed args and path info */
+ r->args = args;
+ r->path_info = path_info;
+}
/* give no advise for time on this subrequest. Perhaps we
* should tally the last mtime amoung all variants, and date
Re: Patch (against trunk) for bug #41960
Hello, Congratulations on the new release 2.2.6. Would there be any possiblity of applying (or reviewing) my outstanding patch? request.c hasn't evolved since I did the patch against trunk. I had also submitted a new test procedure for the test suite. It hasn't yet been commited, although it reproduces the faulty behavior that my patch is intended to fix. I don't know what else to do to be able to submit a valid bug report and potential patch to you: patch against trunk, new test for the perl framework, ... chocolate-chip cookies? I may be missing something in the Apache procedure for submitting this. I would have expected someone to point it out to me since I first submitted the bug report late March. Thanks, -jose
Patch (against trunk) for bug #41960
Hi folks, Just a short messsage to tell you that I just uploaded the patch against svn trunk that fixes this bug. Yes, the patch is still needed as the bug is unfortunately still around :-/. Is there any hope of seeing this patch committed? Our internal production server has been working with it since some months with no side effects. Earlier today I contributed to this list some tests against your svn perl-framework that allows to reproduce the bug. This can be useful if you want to resolve this bug differently. Feel free to contact me if you need further tests or changes to the patch. Best regards and thanks for all your hard work, -jose [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=41960
New test: subrequests and content negotiation
Hi!
Here's my first submission. This test is written against your
perl-framework test environment.
It tests that subrequests are correctly parsing and taking into
account directives that are declared in , sections
and .htaccess files. I'm using the same test scenario I gave in bug
#41960.
Basically, this requires having the following global content-type:
AddType text/html; charset=iso-8859-1 html/htm
The test consists on overloading the charset to utf-8:
AddType text/html; charset=utf-8html/htm
in the test locations under t/apache/subrequests/, one each
for , , and .htaccess. There is a file each
time that is being requested with its complete name
http:///apache/subrequests/.../hello.html
and through content-negotiation:
http:///apache/subrequests/.../hello
It is the content-negotiation that is being processed thru subrequests.
The patch I sent to bug #41960 fixes the subrequest bugs. Without
that patch, one of these tests will return an error (under Apache/2.2.4).
I'm attaching a tgz file which includes a patch to extra.conf.in,
and new files to be stored under t/htdocs/apache/subrequests and
t/subrequests.t The tar archive contains the full hierarchy.
I put this test under t/apache rather than under t/modules because it
is testing subrequests, even if we do so thru content-negotiation. The
tests could be expanded to any other directive that is declared for
a specific location.
Comments are welcome.
Cheers,
-jose
=== inline version of the test and extra.config.in section follows ==
=== subrequests.t
use strict;
use warnings FATAL => 'all';
use Apache::Test;
use Apache::TestRequest;
use Apache::TestUtil;
plan tests => 6, have_module qw(mod_negotiation mod_mime);
## Returns ok if the returned content-type is the same as the
## expected one.
#
sub check_content_type
{
my $path = shift;
my $expected = shift;
my $error_msg = shift;
my $h = HEAD_STR $path;
## parse response headers looking for our headers
my $actual_value;
foreach my $head (split /\n/, $h) {
if ($head =~ /^Content-Type: (.*)$/) {
$actual_value = $1;
last;
}
}
ok t_cmp($actual_value, $expected, $error_msg);
}
## The server is configured to return text/html; charset=iso8859-1 by default
## The different section overrides change this to charset=utf-8.
## We do the test with and without content-negotiation
my $expected_type = "text/html; charset=utf-8";
check_content_type ("/apache/subrequests/dir_override/hello.html",
$expected_type,
"subrequests with overrides");
check_content_type ("/apache/subrequests/dir_override/hello",
$expected_type,
"subrequests with overrides and conn-neg");
check_content_type ("/apache/subrequests/location_override/hello.html",
$expected_type,
"subrequests with overrides");
check_content_type ("/apache/subrequests/location_override/hello",
$expected_type,
"subrequests with overrides and conn-neg");
check_content_type ("/apache/subrequests/htaccess_override/hello.html",
$expected_type,
"subrequests with .htaccess overrides");
check_content_type ("/apache/subrequests/htaccess_override/hello",
$expected_type,
"subrequests with .htaccess overrides and conn-neg");
== extra.conf.in section ==
##
## subrequests test config
##
AddType text/html;charset=iso-8859-1 html htm
Options +MultiViews
AddType text/html;charset=utf-8 html htm
Options +MultiViews
AddType text/html;charset=utf-8 html htm
Options +MultiViews
AllowOverride FileInfo
subrequesttest.tgz
Description: GNU Unix tar archive
How to contribute new tests to the Apache TestSuite?
Hi! I've added some tests to your Perl Framework test suite (latest co from svn). These tests cover subrequests and content-negotiation, following the bug report (and patch) I sent as bug #41960. For these tests, I added a new test script (.t), a new section to extra.conf.in, and a new subdirectory (with content) to htdocs. Could you tell me what is the best way to submit this patch to save you time in its evaluation / integration? And also, what's the easiest way to generate it for you? (svn diff?). Many thanks, -jose
