Re: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59
On 4/3/24 14:26, Eric Covener wrote: Hi all, (After only minor embarrassment of patching tags/2.4.55 instead of 2.4.x...) Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a SHORTENED VOTE to release this candidate tarball httpd-2.4.59-rc1 as 2.4.59: +1 tested on OpenBSD 7.5 (LibreSSL 3.9.0) and Fedora39 Thanks for RMing Giovanni OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58
On 10/16/23 17:08, Stefan Eissing via dev wrote: Hi all, after fixing my merge mistake in rc2 (sorry!), we go again: Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.58-rc3 as 2.4.58: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: 503a7da4a4a27fd496037998b17078dc9fe004db32c657c96cce8356b8aa2eb6 *httpd-2.4.58-rc3.tar.gz sha512: 5c11faf0572035ef67b27775d975999411c689cb774553175299a9e99b63d3d7138b0c7f15048ec28038494d8513689f916202c2289d557947d8b190d46ca9f3 *httpd-2.4.58-rc3.tar.gz The SVN candidate source is found at tags/2.4.58-rc3-candidate. +1 builds and works fine on OpenBSD 7.4 and Fedora 38. Thanks for the RM. Giovanni OpenPGP_signature.asc Description: OpenPGP digital signature
Re: svn commit: r1910267 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/filters/mod_ext_filter.c
On Wed, Jun 07, 2023 at 06:19:13PM +0200, Yann Ylavic wrote:
> On Wed, Jun 7, 2023 at 4:36 PM Ruediger Pluem wrote:
> >
> > On 6/7/23 1:56 PM, Yann Ylavic wrote:
> > > Hi Giovanni;
> > >
> > > On Wed, Jun 7, 2023 at 12:02 AM wrote:
> > >>
> > >> Author: gbechis
> > >> Date: Tue Jun 6 22:02:37 2023
> > >> New Revision: 1910267
> > >>
> > >> URL: http://svn.apache.org/viewvc?rev=1910267=rev
> > >> Log:
> > >> mod_ext_filter: check exit status of filter processes
[...]
> > >> +else if (exitcode != 0) {
> > >> +ap_log_rerror(APLOG_MARK, APLOG_ERR, APR_SUCCESS, r,
> > >> APLOGNO(10453)
> > >> + "child process %s exited with non-zero status
> > >> %d, "
> > >> + "uri=%s", ctx->filter->command, exitcode,
> > >> r->uri);
> > >> +return HTTP_INTERNAL_SERVER_ERROR;
> > >> +}
> > >
> > > HTTP_INTERNAL_SERVER_ERROR (like all HTTP_* statuses) is not an
> > > apr_status_t, it shouldn't be returned by a filter (and does not print
> > > well as an ap_log_rerror() error status for instance like below).
> > >
> > > Maybe use APR_EGENERAL? The error message could be enough to
> > > distinguish them here.
> > > I wouldn't return waitret for the first case either since it's in the
> > > error message already, no need to forward it specifically to the
> > > caller, so APR_EGENERAL still possibly.
> > >
> > >> +}
> > >> +
> > >> +return APR_SUCCESS;
> > >> +}
> > >> +
> > >> /* ef_unified_filter:
> > >> *
> > >> * runs the bucket brigade bb through the filter and puts the result
> > >> into
> > >> @@ -880,6 +914,11 @@ static apr_status_t ef_output_filter(ap_
> > >> if (rv != APR_SUCCESS) {
> > >> ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01468)
> > >>"ef_unified_filter() failed");
> > >> +return rv;
> > >> +}
> > >> +
> > >> +if ((rv = check_filter_process_on_eos(ctx, r)) != APR_SUCCESS) {
> > >> +return rv;
> > >
> > > Not correct here for a filter.
> >
> > I am a little bit confused. Provided that your comments on the
> > check_filter_process_on_eos are considered and the code is changed
> > accordingly, why would it be incorrect for the filter to return this?
>
> Sorry for not being clear. I meant *if the code is not changed* that's
> where a/some/this filter returns an HTTP_ error code instead of an
> apr_status_t, which may confuse any upper filter or logger (not the
> end of the world though, it should hardly be considered something
> recoverable).
>
> >
> > >
> > >> }
> > >>
> > >> if ((rv = ap_pass_brigade(f->next, bb)) != APR_SUCCESS) {
> > >> @@ -939,7 +978,13 @@ static apr_status_t ef_input_filter(ap_f
> > >> }
> > >>
> > >> rv = ef_unified_filter(f, bb);
> > >> -return rv;
> > >> +if (rv != APR_SUCCESS) {
> > >> +ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, f->r, APLOGNO(10454)
> > >> + "ef_unified_filter() failed");
> > >> +return rv;
> > >
> > > Ditto, for both the error log status and return value.
> >
> > Same confusion as above: While ef_unified_filter formally returns an int it
> > looks like its content is actually an apr_status_t.
> > Hence why shouldn't it be used in the log message or returned?
>
> Oh I misread ef_unified_filter() as ef_output_filter() and thought the
> error was propagating here too.
> That's not the case, though now that I look at it in the code (rather
> than the diff only..) it probably makes sense for ef_unified_filter()
> to declare an apr_status_t as returned type (which FWICT it actually
> always returns, as you said).
>
This should fix both issues.
Giovanni
Index: modules/filters/mod_ext_filter.c
===
--- modules/filters/mod_ext_filter.c(revision 1910292)
+++ modules/filters/mod_ext_filter.c(working copy)
@@ -747,13 +747,13 @@
ap_log_rerror(APLOG_MARK, APLOG_ERR, APR_SUCCESS, r, APLOGNO(10452)
"child process %s killed by signal %d, uri=%s",
ctx->filter->command, exitcode, r->uri);
-return HTTP_INTERNAL_SERVER_ERROR;
+return APR_EGENERAL;
}
else if (exitcode != 0) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, APR_SUCCESS, r, APLOGNO(10453)
"child process %s exited with non-zero status %d, "
"uri=%s", ctx->filter->command, exitcode, r->uri);
-return HTTP_INTERNAL_SERVER_ERROR;
+return APR_EGENERAL;
}
}
@@ -766,7 +766,7 @@
* bb, dropping the previous content of bb (the input)
*/
-static int ef_unified_filter(ap_filter_t *f, apr_bucket_brigade *bb)
+static apr_status_t ef_unified_filter(ap_filter_t *f, apr_bucket_brigade *bb)
{
request_rec *r = f->r;
conn_rec *c = r->connection;
signature.asc
Description: PGP signature
Re: [VOTE] Switch read/write repository from Subversion to Git
On 5/4/23 10:34, Ruediger Pluem wrote: This is a formal vote on whether we should move our read/write repository from Subversion to Git. This means that our latest read/write repository will be no longer available via svn.apache.org. It will be available via Git at https://gitbox.apache.org/repos/asf/httpd-site.git and https://github.com/apache/httpd.git. Github also offers the possibility to use a Subversion client: https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients [ ]: Move the read/write repository from Subversion to Git and leverage the features of Github (for now Actions and PR). [ ]: Move the read/write repository from Subversion to Git, but I don't want to work with Github and I will only work with what gitbox.apache.org offers. [ ]: Leave everything as is. [X]: Move the read/write repository from Subversion to Git and leverage the features of Github (for now Actions and PR). Thanks for calling the vote Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))
On 5/3/23 23:03, Christophe JAILLET wrote: Le 03/05/2023 à 21:12, Eric Covener a écrit : On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev wrote: On 25 Apr 2023, at 07:45, Ruediger Pluem wrote: 2. Switching from Subversion to Git is mostly an emotional problem for me. We have some closer ties to Subversion by some overlaps in the community and via mod_dav_svn we kind of partially eat our very own dogfood here by using Subversion. We wouldn't do that any longer with Git. Plus it would switch another of our development tools from an Apache license to GPL. Apart from technical aspects that this change would create we should check if all of the current active committers are fine using Github. While people could use Gitbox and thus avoid Github when we use Git I would like us to leverage the features of Github when we would do this switch and I think this cannot be done if active committers would have issues with Github. +1. I've always found the fight about “must be git” to be really tedious. Github supports both git and svn to this day, and people are free to use what they prefer by using the interface they are most familiar with. While Github is popular today, this is only because the goals of the owners of Github are presently aligned with our goals. As Twitter has taught us, goals change at any time and without warning. Hi Graham -- it's a little unclear to me where this would put you "vote" wise about moving to read/write Git. Anyone else with a stake have an opinion? It has been since about 2019 since we last discussed it here, I am hoping people have warmed up to it. svn or git both fit my needs. git would be slightly easier for me because of the feature to easily commit only parts of changes of files (I think that some svn clients also support it, but not the one I use) github is great because it can be used for code review without the need to commit something. A patch can be discussed, updated, improved, ... cleanly before being merged. That's a great feature IMHO. git/github would also make the project more attractive for others contributions I think. So, even if I personality really don't care for myself, I would +1 the sake of the project. +1 for me to switch to git, code review will be easier. Just a question, how will security diffs be managed in Github ? Giovanni Just my 2c, CJ OpenPGP_signature Description: OpenPGP digital signature
Re: svn commit: r1908972 - /httpd/httpd/trunk/modules/generators/mod_cgid.c
On 4/5/23 08:49, Ruediger Pluem wrote:
On 4/4/23 11:43 PM, gbec...@apache.org wrote:
Author: gbechis
Date: Tue Apr 4 21:43:46 2023
New Revision: 1908972
URL: http://svn.apache.org/viewvc?rev=1908972=rev
Log:
Fix a possible NULL pointer dereference of ap_runtime_dir_relative()
ap_runtime_dir_relative() will return NULL on failure. However cgid_init()
does not check the return value of ap_runtime_dir_relative() and use it
directly.
Fix this bug by adding a NULL check.
Submitted by: Zhou Qingyang
Github: closes #304
Modified:
httpd/httpd/trunk/modules/generators/mod_cgid.c
Modified: httpd/httpd/trunk/modules/generators/mod_cgid.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/generators/mod_cgid.c?rev=1908972=1908971=1908972=diff
==
--- httpd/httpd/trunk/modules/generators/mod_cgid.c (original)
+++ httpd/httpd/trunk/modules/generators/mod_cgid.c Tue Apr 4 21:43:46 2023
@@ -1059,6 +1059,8 @@ static int cgid_init(apr_pool_t *p, apr_
parent_pid = getpid();
tmp_sockname = ap_runtime_dir_relative(p, sockname);
+if (!tmp_sockname)
+return DECLINED;
I think we should log an error before we return as in this case the cgi daemon
will not start.
correct, just added a ap_log_error line, thanks.
Thanks
Giovanni
if (strlen(tmp_sockname) > sizeof(server_addr->sun_path) - 1) {
tmp_sockname[sizeof(server_addr->sun_path)] = '\0';
ap_log_error(APLOG_MARK, APLOG_ERR, 0, main_server, APLOGNO(01254)
Regards
Rüdiger
OpenPGP_signature
Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.57-rc1 as httpd-2.4.57
On 4/2/23 18:10, Eric Covener wrote: Hi all, Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.57-rc1 as 2.4.57: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: bc3e7e540b83ec24f9b847c6b4d7148c55b79b27d102e21227eb65f7183d6b45 *httpd-2.4.57-rc1.tar.gz sha512: 730560d4aab3699aa59716bb75858f8432a902aeab3c380b4d3e0f6813e9ae4e278d3b7fdf63a4e94c07b5100933d8684d76f6095f3d60d48ea0f1458c9ed0b4 *httpd-2.4.57-rc1.tar.gz The SVN candidate source is found at tags/2.4.57-rc1-candidate. +1 tested on Fedora 37 and OpenBSD 7.3 Thanks of RMing Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: svn commit: r1908805 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
On Thu, Mar 30, 2023 at 07:28:20PM +0200, Ruediger Pluem wrote:
>
>
> On 3/30/23 7:19 PM, Ruediger Pluem wrote:
> >
> >
> > On 3/30/23 7:09 PM, gbec...@apache.org wrote:
> >> Author: gbechis
> >> Date: Thu Mar 30 17:09:09 2023
> >> New Revision: 1908805
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1908805=rev
> >> Log:
> >> check for more possible SSL failures
> >> bz #66225
> >>
> >> Modified:
> >> httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
> >>
> >> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
> >> URL:
> >> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1908805=1908804=1908805=diff
> >> ==
> >> --- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
> >> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Thu Mar 30 17:09:09
> >> 2023
> >> @@ -997,10 +997,7 @@ static int ssl_hook_Access_classic(reque
> >> * handshake to proceed. */
> >> modssl_set_reneg_state(sslconn, RENEG_ALLOW);
> >>
> >> -SSL_renegotiate(ssl);
> >> -SSL_do_handshake(ssl);
> >> -
> >> -if (!SSL_is_init_finished(ssl)) {
> >> +if(!SSL_renegotiate(ssl) || !SSL_do_handshake(ssl) ||
> >> !SSL_is_init_finished(ssl)) {
> >
> > Wouldn't
> >
> > if (!(SSL_renegotiate(ssl) && SSL_do_handshake(ssl) &&
> > SSL_is_init_finished(ssl))) {
> >
> > be better as it would stop the calls as soon as one fails (due to boolean
> > shortcuts)?
> > Or is it mandatory that SSL_do_handshake and / or SSL_is_init_finished get
> > executed if one of steps before fails?
>
> Scratch the above. This was already true for the expression in the commit.
> But for SSL_do_handshake only the return value 1 indicates success, all
> values <= 0 indicate failure.
> https://www.openssl.org/docs/man1.1.1/man3/SSL_do_handshake.html
> Hence the proposal would be
>
> if (!SSL_renegotiate(ssl) || (SSL_do_handshake(ssl) != 1) ||
> !SSL_is_init_finished(ssl))
>
good catch, thanks.
Giovanni
> >
> >> ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02225)
> >>"Re-negotiation request failed");
> >> ssl_log_ssl_error(SSLLOG_MARK, APLOG_ERR, r->server);
> >>
> >>
> >>
> >
>
> Regards
>
> Rüdiger
>
Re: svn commit: r1908684 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/cache/mod_cache_disk.c
On 3/28/23 12:49, Joe Orton wrote: On Fri, Mar 24, 2023 at 08:50:19AM -, gbec...@apache.org wrote: Author: gbechis Date: Fri Mar 24 08:50:19 2023 New Revision: 1908684 URL: http://svn.apache.org/viewvc?rev=1908684=rev Log: add error message when storing data to temp file fails. Github: closes #182 Hi Giovanni, thanks for taking care of the PRs, that is really great to see. FYI when you are committing code written by someone else it is customary to include "Submitted by:" in the commit message to give them due credit, like: Submitted by: Name of Person will do There are guidelines here: https://httpd.apache.org/dev/guidelines.html#changes-file-and-subversion-logs If you use Ruediger's apply_trunk_pr.sh script from here: https://svn.apache.org/repos/asf/httpd/dev-tools/github/ it will do this automatically for you for a PR, including extracting the full name properly from the github metadata (which is really neat). thanks, I was not aware of this script. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56
On 3/10/23 16:33, Eric Covener wrote: Saw another report on users@ Any thoughts on something like this to just allow spaces? http://people.apache.org/~covener/patches/rewrite-lax.diff that makes sense, any other possible char that we should allow other then spaces ? Giovanni (this is off my $bigco fork so may not actually apply) On Thu, Mar 9, 2023 at 3:08 PM BUSH Steve wrote: Maybe we can slip an additional entry into the changelog. I think in this case, for now at least, we'd primarily rely on the error_log entry. Did this produce the new AH10410? Yes, the error log did include the AH10410 message. URL encoding the spaces either as \%20 (path or query string) or + (query string) does eliminate the problem for our mappings. From: Eric Covener Sent: Wednesday, March 8, 2023 8:31 PM To: dev@httpd.apache.org Subject: Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56 On Wed, Mar 8, 2023 at 11: 02 PM BUSH Steve wrote: Correction! I used our test template for the rule when I e-mailed just now, but once it is converted to the apache httpd. conf format, the actual rule appears in the ZjQcmQR YFpfptBannerEnd On Wed, Mar 8, 2023 at 11:02 PM BUSH Steve wrote: Correction! I used our test template for the rule when I e-mailed just now, but once it is converted to the apache httpd.conf format, the actual rule appears in the httpd.conf as: RewriteRule ^/zoology/animals/reset/(\d+)$ "/auth/launchjob?Number of Records=$1&__poolid=animal-magic" [B,PT,L,QSA] Thanks for the report. Time will tell, but I think this is a very fringe case. The space isn't a backreference (where `B` would have fixed it) and a literal with a space in the substitution has to be quite rare (famous last words) I just looked at the mod_rewrite.c source differences from 2.4.55 to 2.4.56 and it’s clear that the use of spaces in the query string of the mapped URL are the cause of the 403 forbidden messages. We can update our httpd.conf mapping code, so it won’t be a problem for us, but it might be worth updating the mod_rewrite documentation on this? Maybe we can slip an additional entry into the changelog. I think in this case, for now at least, we'd primarily rely on the error_log entry. Did this produce the new AH10410? This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email. Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer https://www.3ds.com/privacy-policy/contact/ OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56
On 3/9/23 05:30, Eric Covener wrote: On Wed, Mar 8, 2023 at 11:02 PM BUSH Steve mailto:steven.b...@3ds.com>> wrote: Correction! I used our test template for the rule when I e-mailed just now, but once it is converted to the apache httpd.conf format, the actual rule appears in the httpd.conf as: RewriteRule ^/zoology/animals/reset/(\d+)$ "/auth/launchjob?Number of Records=$1&__poolid=animal-magic" [B,PT,L,QSA] Thanks for the report. Time will tell, but I think this is a very fringe case. The space isn't a backreference (where `B` would have fixed it) and a literal with a space in the substitution has to be quite rare (famous last words) I wonder how many websites might have a snippet similar to: RewriteRule ^/search/(.*)$ /search.php?term=$1 [PT,L,QSA] Giovanni I just looked at the mod_rewrite.c source differences from 2.4.55 to 2.4.56 and it’s clear that the use of spaces in the query string of the mapped URL are the cause of the 403 forbidden messages. __ __ We can update our httpd.conf mapping code, so it won’t be a problem for us, but it might be worth updating the mod_rewrite documentation on this? Maybe we can slip an additional entry into the changelog. I think in this case, for now at least, we'd primarily rely on the error_log entry. Did this produce the new AH10410? OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] [VOTE] Release httpd-2.4.56-rc1 as httpd-2.4.56
On 3/5/23 22:31, Eric Covener wrote: Hi all, Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.56-rc1 as 2.4.56: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: db0d4c76007b231fd3ab41b580548dc798ae3844bb7c3d5ce1e4174ca2364698 *httpd-2.4.56-rc1.tar.gz sha512: 68b1e8c3e3436e6947c0ccfeee6fea83254560e4d43bddbc79a4206d804a6dda6662cf5734e0b2f4019ab5c1fff40141a16dd7698e8fe72b7fd343fbebd42724 *httpd-2.4.56-rc1.tar.gz +1 tested on Fedora 37 and OpenBSD 7.2 and 7.3-beta Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.55-rc1 as httpd-2.4.55
On 1/10/23 14:40, Eric Covener wrote: Hi all, Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.55-rc1 as 2.4.55 +1 for release looks fine on OpenBSD 7.2 and CentOS8-Stream (x86_64), thank you for RMing. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.55-rc1 as httpd-2.4.55
On Tue, Jan 10, 2023 at 08:40:52AM -0500, Eric Covener wrote: > Hi all, > > Please find below the proposed release tarball and signatures: > > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release > this candidate tarball httpd-2.4.55-rc1 as 2.4.55: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha256: 5276ea8bc6fff31eed5c82132ae51a0b2ee05f9e6b61a00fa877f6cadab3b638 > *httpd-2.4.55-rc1.tar.gz > sha512: > ca0d03b5e74078977378fe711ca3ed8cf63c109b7dbe73f2c43f7f30f7e522bbe46f93189a183b7675394d57fffb0c2526facd8d40508be984a7a8f64d18f8d6 > *httpd-2.4.55-rc1.tar.gz > > The SVN candidate source is found at tags/2.4.55-rc1-candidate. > on Fedora 37 (gcc 12.2.1 or clang 15.0.6) build fails with: - /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc-std=c89 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security -Wunused -DLINUX -D_REENTRANT -D_GNU_SOURCE -DAP_DEBUG \ -I. -I [...]/httpd/httpd-2.4/modules/mappers -prefer-non-pic -static -c ab.c && touch ab.lo ab.c: In function 'ssl_proceed_handshake': ab.c:769:25: error: 'EVP_PKEY_get1_EC_KEY' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 769 | EC_KEY *ec = EVP_PKEY_get1_EC_KEY(key); | ^~ In file included from /usr/include/openssl/x509.h:29, from ab.c:171: /usr/include/openssl/evp.h:1374:19: note: declared here 1374 | struct ec_key_st *EVP_PKEY_get1_EC_KEY(EVP_PKEY *pkey); | ^~~~ ab.c:770:25: error: 'EC_KEY_get0_group' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 770 | int nid = EC_GROUP_get_curve_name(EC_KEY_get0_group(ec)); | ^~~ In file included from /usr/include/openssl/x509.h:33: /usr/include/openssl/ec.h:1034:39: note: declared here 1034 | OSSL_DEPRECATEDIN_3_0 const EC_GROUP *EC_KEY_get0_group(const EC_KEY *key); | ^ ab.c:771:25: error: 'EC_KEY_free' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 771 | EC_KEY_free(ec); | ^~~ /usr/include/openssl/ec.h:1003:28: note: declared here 1003 | OSSL_DEPRECATEDIN_3_0 void EC_KEY_free(EC_KEY *key); |^~~ ab.c: In function 'start_connect': ab.c:1431:13: error: 'BIO_set_callback' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 1431 | BIO_set_callback(bio, ssl_print_cb); | ^~~~ In file included from /usr/include/openssl/asn1.h:27, from /usr/include/openssl/rsa.h:21, from ab.c:169: /usr/include/openssl/bio.h:279:28: note: declared here 279 | OSSL_DEPRECATEDIN_3_0 void BIO_set_callback(BIO *b, BIO_callback_fn callback); |^~~~ cc1: all warnings being treated as errors - Is this considered a blocker ? This can be workarounded by building with different "-Werror" options. Giovanni signature.asc Description: PGP signature
Re: New committer: Emmanuel Dreyfus
On 11/8/22 11:14, Joe Orton wrote: The Project Management Committee (PMC) for the Apache HTTP Server has invited Emmanuel Dreyfus to become a committer and we are pleased to announce that they have accepted. Welcome, Emmanuel! Welcome Emmanuel, glad to see you here. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: svn commit: r1902318 - in /httpd/httpd/trunk: docs/log-message-tags/next-number server/listen.c
On 6/28/22 15:22, Eric Covener wrote:
> On Tue, Jun 28, 2022 at 9:06 AM wrote:
>>
>> Author: gbechis
>> Date: Tue Jun 28 13:06:55 2022
>> New Revision: 1902318
>>
>> URL: http://svn.apache.org/viewvc?rev=1902318=rev
>> Log:
>> check apr_sockaddr_info_get return value
>> bz #66136
>>
>> Modified:
>> httpd/httpd/trunk/docs/log-message-tags/next-number
>> httpd/httpd/trunk/server/listen.c
>>
>> Modified: httpd/httpd/trunk/docs/log-message-tags/next-number
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-tags/next-number?rev=1902318=1902317=1902318=diff
>> ==
>> --- httpd/httpd/trunk/docs/log-message-tags/next-number (original)
>> +++ httpd/httpd/trunk/docs/log-message-tags/next-number Tue Jun 28 13:06:55
>> 2022
>> @@ -1 +1 @@
>> -10397
>> +10398
>>
>> Modified: httpd/httpd/trunk/server/listen.c
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/listen.c?rev=1902318=1902317=1902318=diff
>> ==
>> --- httpd/httpd/trunk/server/listen.c (original)
>> +++ httpd/httpd/trunk/server/listen.c Tue Jun 28 13:06:55 2022
>> @@ -881,7 +881,12 @@ AP_DECLARE(apr_status_t) ap_duplicate_li
>> duplr->protocol = apr_pstrdup(p, lr->protocol);
>> hostname = apr_pstrdup(p, lr->bind_addr->hostname);
>> port = lr->bind_addr->port;
>> -apr_sockaddr_info_get(, hostname, APR_UNSPEC, port, 0,
>> p);
>> +stat = apr_sockaddr_info_get(, hostname, APR_UNSPEC,
>> port, 0, p);
>> +if (stat != APR_SUCCESS) {
>> +ap_log_perror(APLOG_MARK, APLOG_CRIT, stat, p,
>> APLOGNO(10397)
>> + "unable to control socket status");
>> +return stat;
>> +}
>
> Better message here (even though it's unlikely anyone will ever see it)? e.g.
>
committed, thanks.
Giovanni
> Index: server/listen.c
> ===
> --- server/listen.c (revision 1902318)
> +++ server/listen.c (working copy)
> @@ -884,7 +884,7 @@
> stat = apr_sockaddr_info_get(, hostname,
> APR_UNSPEC, port, 0, p);
> if (stat != APR_SUCCESS) {
> ap_log_perror(APLOG_MARK, APLOG_CRIT, stat, p,
> APLOGNO(10397)
> - "unable to control socket status");
> + "failure looking up %s to duplicate
> listening socket", hostname);
> return stat;
> }
> duplr->bind_addr = sa;
OpenPGP_signature
Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.54-rc3 as httpd-2.4.54
On 6/7/22 12:02, Stefan Eissing wrote: > Seems a lot of people are either on vacation or busy - and that is fine. > > Since the rc* candidates merely differed on the TCP_FLUSH defines, I tend > to count all positive votes as still applicable! > +1 Fedora 36, OpenBSD 7.1 and OpenBSD-current. Giovanni > Otherwise, speak up! > > Kind Regards, > Stefan > >> Am 07.06.2022 um 12:00 schrieb Stefan Eissing : >> >> +1 from me on my macOS machine. >> >>> Am 07.06.2022 um 10:58 schrieb Joe Orton : >>> >>> On Mon, Jun 06, 2022 at 04:25:31PM +0200, Stefan Eissing wrote: >>>> Here we go again! Sorry for the repeats, but that is why we build >>>> candidates, right? >>>> >>>> Hi all, >>>> >>>> Please find below the proposed release tarball and signatures: >>>> >>>> https://dist.apache.org/repos/dist/dev/httpd/ >>>> >>>> I would like to call a VOTE over the next few days to release >>>> this candidate tarball httpd-2.4.54-rc3 as 2.4.54: >>>> [X] +1: It's not just good, it's good enough! >>>> [ ] +0: Let's have a talk. >>>> [ ] -1: There's trouble in paradise. Here's what's wrong. >>>> >>>> The computed digests of the tarball up for vote are: >>>> sha256: c687b99c446c0ef345e7d86c21a8e15fc074b7d5152c4fe22b0463e2be346ffb >>>> *httpd-2.4.54-rc3.tar.gz >>>> sha512: >>>> e9599df48a73b07b3a11dd44db2c22a671e8a41cdd5021bb434bbcde39d6fc498d165d9b0c4ed2b66a6321d9760b031c1c1c84c23661dbf44c42c52f637ec4dd >>>> *httpd-2.4.54-rc3.tar.gz >>> >>> +1 for release, passes tests on Fedora 36, RHEL 8 & 9 (x86_64 only). >>> >>> One note: on F36 I had to manually add a route for the multicast range >>> to get t/modules/heartbeat.t to pass, which I guess is a change in the >>> default network configuration compared to earlier Fedora releases. >>> >>> Thanks for RMing! (x3) >>> >>> Regards, Joe >>> >> > OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.54-rc2 as httpd-2.4.54
On 6/4/22 14:59, Stefan Eissing wrote: > Hi all, > > next attempt at 2.5.54. Thanks everyone for participating! > > Please find below the proposed release tarball and signatures: > > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release > this candidate tarball httpd-2.4.54-rc2 as 2.4.54: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha256: fd461abb356592386e7de90835f888fa4eb0ce225a89986c38108bdcbce466ef > *httpd-2.4.54-rc2.tar.gz > sha512: > 6267d43aca3c278a0b428633a41ddea346d73a1c94fa3e9d54a600e8c7ab71b4a7772c7dbbcd552a802606416c2f6193ceaa0c6bcf07fe2b61cf175cb48b892f > *httpd-2.4.54-rc2.tar.gz > > The SVN candidate source is found at tags/2.4.54-rc2-candidate. > +1 tested on Fedora 36, OpenBSD 7.1 and OpenBSD-current Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.53-rc2 as httpd-2.4.53
On Wed, Mar 09, 2022 at 05:19:22PM +0100, Stefan Eissing wrote: > Hi all, > > Please find below the proposed release tarball and signatures: > > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release > this candidate tarball httpd-2.4.53-rc2 as 2.4.53: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha256: 7a045e8e653aaf931f9667f3a7e1943bd81306bf908f316465f737a854d10c16 > *httpd-2.4.53-rc2.tar.gz > sha512: > 2fa1918aa44eb9984c0a294f416102088ed6874213391acd8c434b062603eb2a9ec64f7b1a218d4fe283d74fc9956650297d0b4dda57dcd8533b075a7321ec78 > *httpd-2.4.53-rc2.tar.gz > > The SVN candidate source is found at tags/2.4.53-rc2-candidate. > +1 from me, works on OpenBSD 7.0, 7.1-beta and Fedora 35. Thanks Giovanni signature.asc Description: PGP signature
Re: backports
On Fri, Mar 04, 2022 at 09:40:49AM -0800, Roy T. Fielding wrote: > > On Mar 4, 2022, at 6:17 AM, Eric Covener wrote: > > > > On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski wrote: > >> > >> A question: Would it be easier for all this if we moved to being Github > >> canon? > > > > I think it is much more straightforward. The original work, reviews > > and travis results are all in the same place and nothing is copied > > around. > > I have had the same thought a few times this week. But I was hesitant > > to reopen that thread/discussion because I'm pessimistic we can get > > anywhere on it. > > I think we are far beyond that point where staying with svn/bugzilla is > actively > hurting the project for little or no benefit. > > I'd +1 a switch just to get real issue management and PRs. > +1 to switch. Giovanni signature.asc Description: PGP signature
Re: [VOTE] Release httpd-2.4.52-rc1 as httpd-2.4.52
On 12/16/21 15:03, Stefan Eissing wrote: > > Hi all, > > Please find below the proposed release tarball and signatures: > > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release > this candidate tarball httpd-2.4.52-rc1 as 2.4.52: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha256: 296c74a8adde1a8acd6617b21fc3d19719ff4fa39319b2bdbd898aca4d5df97f > *httpd-2.4.52-rc1.tar.gz > sha512: > b9012096d6658f7d34a3c655eac31b39ffd439c11de6f3e6e9f309d55f4186a4fb26134eb97522e416ae8ca10ed008a14e96fa01a3e3105d9e547f72e2dc3bc2 > *httpd-2.4.52-rc1.tar.gz > > The SVN candidate source is found at tags/candidate-2.4.52-rc1. > > Kind Regards, > Stefan > +1 for release, works fine on Fedora 35, OpenBSD 7.0 and Debian 11. Regards Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: release vibes?
On 12/8/21 13:56, Joe Orton wrote: > On Mon, Dec 06, 2021 at 11:36:51AM +0100, Stefan Eissing wrote: >> Friends of httpd, how do you feel about a release in the next two weeks? > > Sounds good to me. We may have fewer people around to test it, but at > least trying to get a release out is better than definitely having no > release IMO. > +1 let's try to cook a release. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.50-rc1 as httpd-2.4.50
On 10/1/21 16:40, ste...@eissing.org wrote: > Hi, all; >Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release > this candidate tarball httpd-2.4.50-rc1 as 2.4.50: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: afac1bf6aaa84ea2878c56ed56a49f5efdd7ff73 *httpd-2.4.50-rc1.tar.gz > sha256: feb87f9cc60e02782d795d30cd60a36e918c82fe9a2e7363b0ae28a78be9613a > *httpd-2.4.50-rc1.tar.gz > sha512: > 3b5e06d8428f14bae8173dbb27921496831c7c14c31850d2df0c0d6f69e931bbf0e4e71c6a250b4f5c0d646d1b7da813bbe61711f8a79ab5f80d39dfd176f57c > *httpd-2.4.50-rc1.tar.gz > > The SVN candidate source is found at tags/candidate-2.4.50-rc1. > > Kind Regards, > Stefan > +1 for release, thanks for RMing. All works fine on OpenBSD-6.9, OpenBSD-7.0 and CentOS8. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.49-rc1 as httpd-2.4.49
On 9/10/21 17:23, ste...@eissing.org wrote: > Hi, all; >Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release > this candidate tarball httpd-2.4.49-rc1 as 2.4.49: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. +1, works fine on Fedora 34 and OpenBSD 6.9. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] Re: http2 test suite
On Wed, Sep 01, 2021 at 10:56:15AM +0100, Joe Orton wrote: > On Mon, Aug 30, 2021 at 08:39:17AM +0200, Ruediger Pluem wrote: > > On 8/28/21 4:00 PM, Yann Ylavic wrote: > > > On Fri, Aug 27, 2021 at 10:07 AM ste...@eissing.org > > > wrote: > > >> Related to that, do we exempt "./test" from RTC in 2.4.x/STATUS? > > > > > > +1 for CTR, that's how the tests framework works de facto already (a > > > single framework/trunk is run for both trunk and 2.4.x). > > > > +1 on CTR for this. > > +1 from me too to make test/ CTR for 2.4.x, let's make this a proper > vote thread. > > (I would hold off a week or so on enabling the h2 tests in Travis for > 2.4.x until we are confident they are stable in trunk CI runs) > +1 Regards Giovanni signature.asc Description: PGP signature
Re: disallow HTTP 0.9 by default?
On 7/21/21 10:04 PM, Eric Covener wrote: > I was chasing an unrelated thread about close_notify alerts and > reminded me -- is it time to change the default for > HttpProtocolOptions from Allow0.9 to Require1.0? > > As the manual says, the requirement was dropped in RFC 7230. It seems > like the kind of potential gadget in future desynch/smuggling kind of > attacks that shouldn't be on by default today. > +1, httpd 0.9 is old enough and it's time to deprecate it. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: Security policy on Github
On 6/25/21 9:15 AM, Ruediger Pluem wrote: > I would like to suggest that we fill a very basic document that shows on > Github as our security policy. > Below my proposal for a SECURITY.md : > > > === > # Security Policy > > ## Supported Versions > > Currently the only supported version is the latest patch release of the > 2.4.x stable branch. > > ## Security Updates > > [Apache 2.4 Security > Vulnerabilities](http://httpd.apache.org/security/vulnerabilities_24.html) > > ## Reporting a Vulnerability > > For information on how to report a new security problem please see > [here](http://httpd.apache.org/security_report.html) > = > > Any objections? > Great idea, +1. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.48
On Wed, May 19, 2021 at 07:43:51PM +0200, Christophe JAILLET wrote: > Le 18/05/2021 à 14:57, Giovanni Bechis a écrit : > > On 5/18/21 1:53 PM, Joe Orton wrote: > >> On Tue, May 18, 2021 at 01:30:25PM +0200, Ruediger Pluem wrote: > >>> > >>> > >>> On 5/18/21 11:52 AM, Giovanni Bechis wrote: > >>>> On 5/17/21 11:36 PM, Christophe JAILLET wrote: > >>>>> Hi, all; > >>>>> Please find below the proposed release tarball and signatures: > >>>>> https://dist.apache.org/repos/dist/dev/httpd/ > >>>>> > >>>>> I would like to call a VOTE over the next few days to release this > >>>>> candidate tarball as 2.4.48: > >>>>> [ ] +1: It's not just good, it's good enough! > >>>>> [ ] +0: Let's have a talk. > >>>>> [ ] -1: There's trouble in paradise. Here's what's wrong. > >>>>> > >>>>> The computed digests of the tarball up for vote are: > >>>>> sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz > >>>>> sha256: > >>>>> 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e > >>>>> *httpd-2.4.48.tar.gz > >>>>> sha512: > >>>>> 91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb > >>>>> *httpd-2.4.48.tar.gz > >>>>> > >>>>> The SVN tag is '2.4.48' at r1889975. > >>>>> > >>>> -1 for me. > >>>> new mod_md doesn't build with LibreSSL because nor EVP_PKEY_X25519 nor > >>>> EVP_PKEY_X448 are defined. > >>>> I have asked LibreSSL guys if they will add EVP_PKEY_* constants to > >>>> evp.h. > > Hi Giovanni, > > From my point of view, we do not *officially* support LibreSSL. The > mod_ssl doc is only about OpenSSL. I've found no reference to it, apart > from the many LIBRESSL_VERSION_NUMBER in the code itself. > So, even if the LibreSSL built was completely broken, I wouldn't > consider it as a showstoper. > > If we consider that Linking against LibreSSL is a must have, then, at > least we should update the doc. > I have several Apache httpd + LibreSSL setups and I would like to keep them working I will work to have LibreSSL compatibility as much as I can. > >>> > >>> Did 2.4.46 build with LibreSSL? > >> > > 2.4.46 and 2.4.47 builds. > > >> Looks like this is new in 2.4.48 but both LibreSSL users can work around > >> this or not build mod_md, it doesn't seem like a showstopper. > >> > > no real showstopper for me, please remove my "-1" vote. > > > > Let us know if you want to change your vote to something else (see [1]) > or if you just don't vote for this release. > +1 for me then, I can backport patches where needed. > > > >> Giovanni, if you care about keeping Libre support alive can you work out > >> how to get it building in Travis? It's daft if we are only hitting > >> these compat issues in post-roll testing. > >> > > I agree and I will take a look at it. > > Just great :) > Thx. > > And then, updating the doc would worth it ;-) > This will be one of the first steps. Giovanni > CJ > > [1]: > https://apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions > signature.asc Description: PGP signature
Re: [VOTE] Release httpd-2.4.48
On 5/18/21 1:53 PM, Joe Orton wrote: > On Tue, May 18, 2021 at 01:30:25PM +0200, Ruediger Pluem wrote: >> >> >> On 5/18/21 11:52 AM, Giovanni Bechis wrote: >>> On 5/17/21 11:36 PM, Christophe JAILLET wrote: >>>> Hi, all; >>>> Please find below the proposed release tarball and signatures: >>>> https://dist.apache.org/repos/dist/dev/httpd/ >>>> >>>> I would like to call a VOTE over the next few days to release this >>>> candidate tarball as 2.4.48: >>>> [ ] +1: It's not just good, it's good enough! >>>> [ ] +0: Let's have a talk. >>>> [ ] -1: There's trouble in paradise. Here's what's wrong. >>>> >>>> The computed digests of the tarball up for vote are: >>>> sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz >>>> sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e >>>> *httpd-2.4.48.tar.gz >>>> sha512: >>>> 91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb >>>> *httpd-2.4.48.tar.gz >>>> >>>> The SVN tag is '2.4.48' at r1889975. >>>> >>> -1 for me. >>> new mod_md doesn't build with LibreSSL because nor EVP_PKEY_X25519 nor >>> EVP_PKEY_X448 are defined. >>> I have asked LibreSSL guys if they will add EVP_PKEY_* constants to evp.h. >> >> Did 2.4.46 build with LibreSSL? > 2.4.46 and 2.4.47 builds. > Looks like this is new in 2.4.48 but both LibreSSL users can work around > this or not build mod_md, it doesn't seem like a showstopper. > no real showstopper for me, please remove my "-1" vote. > Giovanni, if you care about keeping Libre support alive can you work out > how to get it building in Travis? It's daft if we are only hitting > these compat issues in post-roll testing. > I agree and I will take a look at it. > Regards, Joe > OpenPGP_signature Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.48
On 5/17/21 11:36 PM, Christophe JAILLET wrote:
> Hi, all;
> Please find below the proposed release tarball and signatures:
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release this candidate
> tarball as 2.4.48:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz
> sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e
> *httpd-2.4.48.tar.gz
> sha512:
> 91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb
> *httpd-2.4.48.tar.gz
>
> The SVN tag is '2.4.48' at r1889975.
>
-1 for me.
new mod_md doesn't build with LibreSSL because nor EVP_PKEY_X25519 nor
EVP_PKEY_X448 are defined.
I have asked LibreSSL guys if they will add EVP_PKEY_* constants to evp.h.
Giovanni
The following patch is a workaround:
Index: modules/md/md_crypt.c
--- modules/md/md_crypt.c.orig
+++ modules/md/md_crypt.c
@@ -71,6 +71,11 @@
#include
#endif
+#if defined(LIBRESSL_VERSION_NUMBER)
+#define EVP_PKEY_X25519 NID_X25519
+#define EVP_PKEY_X448 NID_X448
+#endif
+
static int initialized;
struct md_pkey_t {
OpenPGP_signature
Description: OpenPGP digital signature
Re: [VOTE] Release httpd-2.4.47
On 4/22/21 11:25 AM, Christophe JAILLET wrote: > Hi, all; > Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this candidate > tarball as 2.4.47: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: f4281be0bf08489a51d818b596a92bfcfbb2c708 *httpd-2.4.47.tar.gz > sha256: 567d5ac72ea643e3828e8e54f32e06f1fad10095d33ae4071eeaec3c78b70a34 > *httpd-2.4.47.tar.gz > sha512: > de4c80e1ddebe3286c234179fd01d4917f479f75a7fe958032c19a8f22546e95f31e3b50073844d09f20f54894e7d511bcd9fd2f1cd2b2c71b3a182d6e62bab3 > *httpd-2.4.47.tar.gz > > The SVN tag is '2.4.47' at r1889091. > +1, works fine on Fedora33 and OpenBSD 6.9. Thanks for taking up the RM. Giovanni OpenPGP_signature Description: OpenPGP digital signature
Re: svn commit: r1881590 - /httpd/httpd/trunk/modules/http/http_filters.c
On 9/10/20 4:14 PM, Ivan Zhakov wrote:
>
>
> On Wed, 9 Sep 2020 at 17:43, mailto:gbec...@apache.org>>
> wrote:
>
> Author: gbechis
> Date: Wed Sep 9 14:43:07 2020
> New Revision: 1881590
>
> URL: http://svn.apache.org/viewvc?rev=1881590=rev
> Log:
> handle headers when replying a 304 following rfc7234
> as discussed in bz 61820
>
> Modified:
> httpd/httpd/trunk/modules/http/http_filters.c
>
> Modified: httpd/httpd/trunk/modules/http/http_filters.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=1881590=1881589=1881590=diff
>
> ==
> --- httpd/httpd/trunk/modules/http/http_filters.c (original)
> +++ httpd/httpd/trunk/modules/http/http_filters.c Wed Sep 9 14:43:07 2020
> @@ -1427,25 +1427,21 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_
> h.bb <http://h.bb> = b2;
>
> if (r->status == HTTP_NOT_MODIFIED) {
> - apr_table_do((int (*)(void *, const char *, const char *))
> form_header_field,
> - (void *) , r->headers_out,
> - "Connection",
> - "Keep-Alive",
> - "ETag",
> - "Content-Location",
> - "Expires",
> - "Cache-Control",
> - "Vary",
> - "Warning",
> - "WWW-Authenticate",
> - "Proxy-Authenticate",
> - "Set-Cookie",
> - "Set-Cookie2",
> - NULL);
> - }
> - else {
> - send_all_header_fields(, r);
> + /*
> + * List of headers that must not be updated on a 304 (or 206
> partial content)
> + * https://tools.ietf.org/id/draft-ietf-httpbis-cache-08.txt
> + */
> + apr_table_unset(r->headers_out, "Content_Encoding");
> + apr_table_unset(r->headers_out, "Content_Length");
> + apr_table_unset(r->headers_out, "Content_MD5");
> + apr_table_unset(r->headers_out, "Content_Range");
> + apr_table_unset(r->headers_out, "ETag");
> + apr_table_unset(r->headers_out, "TE");
> + apr_table_unset(r->headers_out, "Trailer");
> + apr_table_unset(r->headers_out, "Transfer_Encoding");
>
> Maybe I am missing some context, but header names use dash, not underscore.
> I.e Content-Encoding, not Content_Encoding.
>
fixed in r1881624, thanks.
Giovanni
Re: [VOTE] Release httpd-2.4.46
On 8/1/20 4:13 PM, Daniel Ruggeri wrote: > Hi, all; > Third time is a charm! Please find below the proposed release tarball > and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this > candidate tarball as 2.4.46: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: 15adb7eb3dc97e89c8a4237901a9d6887056ab98 *httpd-2.4.46.tar.gz > sha256: 44b759ce932dc090c0e75c0210b4485ebf6983466fb8ca1b446c8168e1a1aec2 > *httpd-2.4.46.tar.gz > sha512: > 5801c1dd0365f706a5e2365e58599b5adac674f3c66b0f39249909841e6cdf16bfdfe001fbd668f323bf7b6d14b116b5e7af49867d456336fad5e685ba020b15 > *httpd-2.4.46.tar.gz > > The SVN tag is '2.4.46' at r1880505. > +1, tested on Fedora32 and OpenBSD-current. Giovanni
Re: [VOTE] Release httpd-2.4.45
On 7/29/20 5:26 PM, Daniel Ruggeri wrote: > Hi, all; > Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this > candidate tarball as 2.4.45: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: 98d470cee244a41ac933f44428ebf10149639a8c *httpd-2.4.45.tar.gz > sha256: 653b4f24eca6852e1b6248f6dc9a6674b647fdc4d1d4583f46bd8a6c8ee049ae > *httpd-2.4.45.tar.gz > sha512: > 8b1e9c22371c75efd2466c69ed48782ddcecfe0a3ff143ca3f9cb720ea2aee56f5c323a9e3ae80cd5c44f1601b5894879af03b6b3729a8ca0555bb5193a1296a > *httpd-2.4.45.tar.gz > > The SVN tag is '2.4.45' at r1880411. > +1, builds and works fine on Fedora 32 and OpenBSD current. Thanks for the release Giovanni
Re: svn commit: r1878462 - /httpd/httpd/trunk/modules/md/md_json.c
On 6/4/20 9:50 AM, ste...@eissing.org wrote:
>
>
>> Am 04.06.2020 um 09:04 schrieb gbec...@apache.org:
>>
>> Author: gbechis
>> Date: Thu Jun 4 07:04:09 2020
>> New Revision: 1878462
>>
>> URL: http://svn.apache.org/viewvc?rev=1878462=rev
>> Log:
>> Add error checks in md_json_readb
>>
>> Modified:
>>httpd/httpd/trunk/modules/md/md_json.c
>>
>> Modified: httpd/httpd/trunk/modules/md/md_json.c
>> URL:
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/md/md_json.c?rev=1878462=1878461=1878462=diff
>> ==
>> --- httpd/httpd/trunk/modules/md/md_json.c (original)
>> +++ httpd/httpd/trunk/modules/md/md_json.c Thu Jun 4 07:04:09 2020
>> @@ -1101,11 +1101,14 @@ apr_status_t md_json_readb(md_json_t **p
>> json_t *j;
>>
>> j = json_load_callback(load_cb, bb, 0, );
>> -if (!j) {
>> -return APR_EINVAL;
>> +if (j) {
>> +*pjson = json_create(pool, j);
>> +} else {
>> +md_log_perror(MD_LOG_MARK, MD_LOG_ERR, 0, pool,
>> + "failed to load JSON file: %s (line %d:%d)",
>> + error.text, error.line, error.column);
>> }
>> -*pjson = json_create(pool, j);
>> -return APR_SUCCESS;
>> +return (j && *pjson) ? APR_SUCCESS : APR_EINVAL;
>> }
>>
>> static size_t load_file_cb(void *data, size_t max_len, void *baton)
>
> This does not seem to hurt, but how does it help? json_create() always
> succeeds in our server, since failed pool allocations lead to an abort. Did I
> miss something?
>
there is similar code in md_json and it doesn't hurt at least.
Giovanni
Re: RFC: mod_ssl features to dump for 2.5
On 5/6/20 1:01 PM, Joe Orton wrote: > On Wed, May 06, 2020 at 11:44:37AM +0100, Joe Orton wrote: >> On Mon, May 04, 2020 at 05:23:23PM +0200, Ruediger Pluem wrote: >>> On 5/4/20 3:49 PM, Joe Orton wrote: >>>> d) SSLRandomSeed. This might have made sense in 1998 but at least with >>>> OpenSSL 1.1.1 which has a rewritten and fork-safe RAND, I think httpd >>>> should not be doing RAND seeding ever. Currently mod_ssl will splat >>>> random stack data, time() and the pid into the RNG state for each new >>>> connection. Unless someone can prove this is valuable and the OpenSSL >>>> PRNG is somehow broken OOTB, I think this code + directive should be >>>> dropped for OpenSSL 1.1.1+, including EGD support etc. >>> >>> Do we drop it only for OpenSSL 1.1.1 or are there other older versions of >>> OpenSSL where this is save to drop? >> >> From https://wiki.openssl.org/index.php/Random_fork-safety it seems like >> there is some reason to believe the <1.1.1 RNG is not safe after fork >> unless you help it. >> >> I was looking at the Fedora default mod_ssl config which does have a >> default "SSLRandom", but the example httpd-ssl.conf shipped does not. So >> *maybe* configuring SSLRandomSeed is useful, but really if it is not >> needed by default we should do something by default, which we don't. > > ^ Apologies for garbled grammar, I meant: > > "if it IS needed by default, we should do something by default" > > ... and we *do* have something configured by default: > > # Note: The following must must be present to support > # starting without SSL on platforms with no /dev/random equivalent > # but a statically compiled-in mod_ssl. > # > > SSLRandomSeed startup builtin > SSLRandomSeed connect builtin > > > but if OpenSSL does not have entropy source beyond that provided by > mod_ssl calling getpid() and time() it is IMO far better to fail to > start up. > > So maybe we should still call RAND_status() and fail startup if the PRNG > is not initialized correctly? > I think we should fail startup, it's better to fail then to give the user a false sense of security and use a poor PRNG. Giovanni
Re: Env var default value
On 4/22/20 1:13 PM, Ruediger Pluem wrote:
>
>
> On 4/22/20 12:50 PM, Yann Ylavic wrote:
>> On Wed, Apr 22, 2020 at 12:10 PM Yann Ylavic wrote:
>>>
>>>> ':'
>>>
>>> This one looks special already in ap_resolve_env(), though it's
>>> forbidden in Define so that may be it.
>>
>> I'm afraid ':' will collide with mod_rewrite's
>> "${mapname:key|default}" syntax for RewriteMap.
>> Same goes for '|' it seems, naming discussion still open :)
>>
>> bash uses '=' for the default value too, looks quite readable/meaningful to
>> me..
>
> '=' seems to be a good candidate as I would suppose that it is rarely used in
> variable names.
>
I like both the idea and the '=' choice, +1.
Giovanni
Re: ssl memory leak, PR 63687
Il 15 aprile 2020 13:36:05 CEST, Yann Ylavic ha scritto: >On Wed, Apr 15, 2020 at 1:18 PM Yann Ylavic >wrote: >> >> In this particular patch, setting "rv" and using a single label may >be >> an option too. Something like this for each goto: >>rv = 0|1; >>goto cleanup; >> ? > >Would look like the attached, FWIW.. +1, best of both words. Giovanni
Re: Fwd: [Bug 63687] High Memory usage after upgrade to 2.4.41
It reads ok, I think there could be other cases later in the code where X509_free(issuer) should be called (after if(cinf) IMHO). Giovanni On 4/7/20 9:36 AM, Stefan Eissing wrote: > Oops. Reading my merged change, I see that we do not free the "X590 *issuer" > from line 134, ssl_util_stapling.c when stapling is not active. Can anyone > confirm my read? Then I'd make a patch to attach to the PR. > > ~icing > >> Anfang der weitergeleiteten Nachricht: >> >> *Von: *bugzi...@apache.org <mailto:bugzi...@apache.org> >> *Betreff: **[Bug 63687] High Memory usage after upgrade to 2.4.41* >> *Datum: *6. April 2020 um 18:01:27 MESZ >> *An: *b...@httpd.apache.org <mailto:b...@httpd.apache.org> >> *Antwort an: *"Apache HTTPD Bugs Notification List" > <mailto:b...@httpd.apache.org>> >> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=63687 >> >> --- Comment #81 from Curtis Wilson --- >> So after determining the trigger for causing this to happen (Reloads) we were >> able to track this down to a specific commit that was causing this issues, >> and >> building a build without this commit and installing it to test servers we did >> find that without this commit the memory issues that have been happening no >> longer are occuring. >> >> >> >> $ git bisect good >> 734313ca6e758f94ae3f923f801f34da02251b9b is the first bad commit >> commit 734313ca6e758f94ae3f923f801f34da02251b9b >> Author: Stefan Eissing >> Date: Tue Jul 30 11:23:52 2019 + >> >> Merged /httpd/httpd/trunk:r1851621,1852128,1862075 >> >> *) mod_ssl/mod_md: reversing dependency by letting mod_ssl offer hooks >> for >> adding certificates and keys to a virtual host. An additional hook >> allows >> answering special TLS connections as used in ACME challenges. >> Adding 2 new hooks for init/get of OCSP stapling status information >> when >> other modules want to provide those. Falls back to own implementation >> with >> same behaviour as before. >> >> >> >> git-svn-id: >> https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1863988 >> 13f79535-47bb-0310-9956-ffa450edef68 >> >> CHANGES | 8 +++ >> modules/ssl/mod_ssl.h | 29 ++ >> modules/ssl/mod_ssl_openssl.h | 40 ++ >> modules/ssl/ssl_engine_init.c | 116 >> +--- >> modules/ssl/ssl_engine_kernel.c | 74 + >> modules/ssl/ssl_util_stapling.c | 93 +--- >> 6 files changed, 253 insertions(+), 107 deletions(-) >> >> -- >> You are receiving this mail because: >> You are the assignee for the bug. >> - >> To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org >> For additional commands, e-mail: bugs-h...@httpd.apache.org >> >
Re: [VOTE] Release httpd-2.4.43
On 3/26/20 3:50 PM, Daniel Ruggeri wrote: > Hi, all; > Please find below the proposed release tarball and signatures: > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days to release this > candidate tarball as 2.4.43: > [ ] +1: It's not just good, it's good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > Works fine on both Fedora 31 and OpenBSD 6.6-current. Thanks Giovanni
Re: sha512 in releases?
On 3/17/20 1:39 PM, jean-frederic clere wrote: > Hi, > > Are we planing to add sha512 in our release? > vcpkg (https://github.com/microsoft/vcpkg) for example uses sha512 to check > the files it downloads. I think we should go that way even if it's not mandatory: "For new releases, PMCs MUST supply SHA-256 and/or SHA-512" (https://www.apache.org/dev/release-distribution#sigs-and-sums). Giovanni
Re: svn commit: r1874545 - /httpd/httpd/trunk/modules/filters/mod_brotli.c
On Wed, Feb 26, 2020 at 10:39:02PM +0100, Marion & Christophe JAILLET wrote: > > Le 26/02/2020 à 18:47, gbec...@apache.org a écrit : > > Author: gbechis > > Date: Wed Feb 26 17:47:53 2020 > > New Revision: 1874545 > > > > URL: http://svn.apache.org/viewvc?rev=1874545=rev > > Log: > > Avoid printing NULL strings in logs > > > > Modified: > > httpd/httpd/trunk/modules/filters/mod_brotli.c > > > > Modified: httpd/httpd/trunk/modules/filters/mod_brotli.c > > URL: > > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_brotli.c?rev=1874545=1874544=1874545=diff > > == > > --- httpd/httpd/trunk/modules/filters/mod_brotli.c (original) > > +++ httpd/httpd/trunk/modules/filters/mod_brotli.c Wed Feb 26 17:47:53 2020 > > @@ -419,7 +419,7 @@ static apr_status_t compress_filter(ap_f > > } > > q = ap_get_token(r->pool, , 1); > > ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r, > > - "token: '%s' - q: '%s'", token, q); > > + "token: '%s' - q: '%s'", token ?: "NULL", q); > > Is this syntax standard? This looks like a GNU extension. > > Shouldn't we use > token ? token : "NULL" > instead? > > A few google search make me think that it could be an issue with VS > (i.e. windows build) > > Just my 2c. > > CJ > you are right, committed thanks. Giovanni signature.asc Description: PGP signature
Re: error on fedora31 when configure --enable-maintainer-mode
On 2/26/20 5:07 PM, jean-frederic clere wrote: > Hi, > > I have 2 errors when compile on fedora31 with configure > --enable-maintainer-mod. Attached a possible patch, comments? > Thanks, they are both fixed in trunk in 2 separate commits, see https://bz.apache.org/bugzilla/show_bug.cgi?id=64178. Giovanni
Re: AW: KeepAliveTimeout vs. event issue
On 2/20/20 8:36 AM, Pluem, Ruediger, Vodafone Group wrote: > > >> -Ursprüngliche Nachricht- >> Von: Eric Covener >> Gesendet: Mittwoch, 19. Februar 2020 17:41 >> An: Apache HTTP Server Development List >> Betreff: KeepAliveTimeout vs. event issue >> >> IIUC event MPM can close keepalive connections up to 100ms than the >> configured value. >> >> If other software parses the Keep-Alive response header and fudges the >> result by e.g. tens of milliseconds for its own TTL to avoid races, >> should we internally try to avoid these whole-second >> keepalivetimeouts? For example under event adding the 100ms back in >> so at worst the timeout occurs in the same timeout=X advertised? > > Just to be sure I get the issue correct. You say that with event a keepalive > connection might be kept open for x s + 100 ms if keepalivetimeout > is configured to x? > And the client thinks it is only kept open for x seconds as we announce > timeout=x in the keep-alive header? > > I was not able to find any current RFC that describes the keep-alive > response header. I only found what Mozilla documents here: > > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive > > And there they say that timeout is the *minimum* time the connection is > kept alive. So if we keep it open longer this would be fine. > Same thing is written in this draft: "A host MAY keep an idle connection open for longer than the time that it indicates, but it SHOULD attempt to retain a connection for at least as long as indicated." https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#keep-alive Regards Giovanni > Or is it exactly the other way around? Does event close it after > x s - 100 ms and hence earlier than announced? > > Regards > > Rüdiger >
Re: svn commit: r1874007 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_util_ocsp.c
On 2/14/20 6:05 PM, Marion & Christophe JAILLET wrote: > Hi, > > purely speculative, but does a: > apr_table_set(headers, "Connection", "close"); > > around line 812 of md_oscp.c also makes sense? > I think it makes absolutely sense. Giovanni > CJ > > Le 14/02/2020 à 10:38, rpl...@apache.org a écrit : >> Author: rpluem >> Date: Fri Feb 14 09:38:12 2020 >> New Revision: 1874007 >> >> URL: http://svn.apache.org/viewvc?rev=1874007=rev >> Log: >> * modules/ssl/ssl_util_ocsp.c (serialize_request): Set the Connection header >> to close to indicate that we do not want to keep the HTTP connection to >> the >> OCSP responder alive. We don't reuse the connections currently and if the >> OCSP responder keeps the connection alive this could cause us to wait for >> keepalive timeout of the OCSP responder to timeout until we finish our >> reading of the OCSP response. >> >> PR: 64135 >> >> >> Modified: >> httpd/httpd/trunk/CHANGES >> httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c >> >> Modified: httpd/httpd/trunk/CHANGES >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1874007=1874006=1874007=diff >> == >> --- httpd/httpd/trunk/CHANGES [utf-8] (original) >> +++ httpd/httpd/trunk/CHANGES [utf-8] Fri Feb 14 09:38:12 2020 >> @@ -1,6 +1,9 @@ >> -*- coding: utf-8 >> -*- >> Changes with Apache 2.5.1 >> + *) mod_ssl: Do not keep connections to OCSP responders alive when doing >> + OCSP requests. PR 64135. [Ruediger Pluem] >> + >> *) mod_ssl: Disable client verification on ACME ALPN challenges. Fixes >> github >> issue mod_md#172 (https://github.com/icing/mod_md/issues/172). >> [Michael Kaufmann , Stefan Eissing] >> >> Modified: httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c?rev=1874007=1874006=1874007=diff >> == >> --- httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c (original) >> +++ httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c Fri Feb 14 09:38:12 2020 >> @@ -46,6 +46,7 @@ static BIO *serialize_request(OCSP_REQUE >> BIO_printf(bio, "%s%s%s HTTP/1.0\r\n" >> "Host: %s:%d\r\n" >> "Content-Type: application/ocsp-request\r\n" >> + "Connection: close\r\n" >> "Content-Length: %d\r\n" >> "\r\n", >> uri->path ? uri->path : "/", >> >>
Fw: new message
Hey! New message, please read <http://dealninhthuan.com/passing.php?f> Giovanni Donelli This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx
Re: mod_proxy chaining with a .pac file
Great. Thanks! This solve 50% of the problem. The other problem is to actually plug this into mod_proxy. Is there a hook a can use to override the connection to the remote server? What do you guys suggest? thanks! On Jan 24, 2008 12:50 PM, Ralf Mattes [EMAIL PROTECTED] wrote: On Wed, 2008-01-23 at 22:19 +, Giovanni Donelli wrote: Are you talking about a JS lib or a code that does what I need, support for .pac proxy chaning? The later. Sorry, that library wasn't linked to from your original post, but it can be found on the wikipedia page. Here's a direct link: http://code.google.com/p/pacparser/ From browsing the documentation it looks like it does all you need. HTH RalfD As with regards with JS I was going to use the WebKit's JavaScriptCore. There _IS_ a library (C and python(?) interface) - downloadable from the google code link posted in the first message ... trivial to link into an Apache module. AFAIK it uses the mozilla JS code. Cheers, RalfD Joe
Re: mod_proxy chaining with a .pac file - OFF-TOPIC?
Take this pac file:
$ curl http://wpad.wws.lan/wpad.dat
function FindProxyForURL(url, host)
{
// simple hostname
if (dnsDomainLevels(host) == 0) {return DIRECT;}
// match Host against local domains (w/ optional :port)
var dom = /(127\.\d+\.\d+\.\d+|\.wws\.lan\.?|\.local\.?)(:\d+)?/;
if(dom.test(host)) { return DIRECT; }
// All other requests go through port 8080 of proxy
// should that fail to respond, go direct:
return PROXY proxy.wws.lan:8080; DIRECT;
}
Obviously the browser needs to evaluate the URL each time it wants to make
an http request. So I want to do that in my proxy.
Currently proxy chaning in mod_proxy supports only say:
ProxyRemote * x.y.z.w
Now not having found mod_proxy can help me in that, I thought about writing
a mod that in apache would interpret a pac file. In my configuration, the
browser can not be aware of the pac file, only my proxy.
I tried to explain you what was my project doing, instead of asking how
override the connection to a server.
if this is not a subject of interest of this group, I do apologize for
having misunderstood the aim of it. However I still don't understand why
this should be offtopic.
Giovanni
PS: I couldn't figure out a way to search into archives from
http://mail-archives.apache.org/mod_mbox/httpd-modules-dev/. I used google
site: option, and found no entry for pac or wpad.
On Jan 22, 2008 6:20 PM, Joe Lewis [EMAIL PROTECTED] wrote:
First, I want to apologize for keeping this off-topic conversation one
last time on the mailing list. I think if we allow this to be archived,
any questions should be more easily answered using archives, hopefully
reducing our work load.
Giovanni Donelli wrote:
Hi
Thanks for your reply. I do apologize for not being clear. I will
try to restate what I want to achieve. For the sake of this discussion
allow me to simplify the browser/internet interaction as follows:
User enters URL in browser - **browser resolves domain name** -
connect to server x - HTTP request
In the way the browser **resolves** the DNS is where the pac file is
used.
You may want to read and understand the specification first. Remember
that browsers do not reconfigure each time a page is hit - they obtain
the configuration once (via a direct URL to a .pac, a DHCP response, or
a DNS lookup for a wpad hostname - it's in the spec).
The only time in those activities that apache could be involved is in
the direct URL to a .pac file - and it's a static .pac file you drop on
the web server, or serve the proxy.dat file that the DHCP specified or
the DNS method is trying to find. In any way, nothing according to
apache is occurring that is dynamic - it's just serving a .pac or .dat
file.
Which means there is no need to set up an apache module that handles
stuff like this unless you are really crazy and want to construct a
dynamically generated .pac/.dat file (I would not suggest this).
If that is the direction you want to go, we may be able to assist -
however, I doubt that is what you want. Most proxy servers have static
IP addresses, which means the .pac/.dat file should be static as well.
Once again, may apologies to those who are expecting module development
assistance in this as we're not sure we even need it yet.
Joe
--
Joseph Lewis http://sharktooth.org/
Divide the fire, and you will sooner put it out. - Publius Syrus
Re: mod_proxy chaining with a .pac file - OFF-TOPIC?
I am trying to make Apache follow the same rules as the browser
On Jan 23, 2008 2:34 PM, Joe Lewis [EMAIL PROTECTED] wrote:
Giovanni Donelli wrote:
Take this pac file:
$ curl http://wpad.wws.lan/wpad.dat
function FindProxyForURL(url, host)
{
// simple hostname
if (dnsDomainLevels(host) == 0) {return DIRECT;}
// match Host against local domains (w/ optional :port)
var dom = /(127\.\d+\.\d+\.\d+|\.wws\.lan\.?|\.local\.?)(:\d+)?/;
if(dom.test(host)) { return DIRECT; }
// All other requests go through port 8080 of proxy
// should that fail to respond, go direct:
return PROXY proxy.wws.lan:8080; DIRECT;
}
Obviously the browser needs to evaluate the URL each time it wants to
make
an http request. So I want to do that in my proxy.
Currently proxy chaning in mod_proxy supports only say:
ProxyRemote * x.y.z.w
Now not having found mod_proxy can help me in that, I thought about
writing
a mod that in apache would interpret a pac file. In my configuration,
the
browser can not be aware of the pac file, only my proxy.
I tried to explain you what was my project doing, instead of asking how
override the connection to a server.
if this is not a subject of interest of this group, I do apologize for
having misunderstood the aim of it. However I still don't understand why
this should be offtopic.
Giovanni
PS: I couldn't figure out a way to search into archives from
http://mail-archives.apache.org/mod_mbox/httpd-modules-dev/. I used
google
site: option, and found no entry for pac or wpad.
On Jan 22, 2008 6:20 PM, Joe Lewis [EMAIL PROTECTED] wrote:
First, I want to apologize for keeping this off-topic conversation one
last time on the mailing list. I think if we allow this to be
archived,
any questions should be more easily answered using archives, hopefully
reducing our work load.
Giovanni Donelli wrote:
Hi
Thanks for your reply. I do apologize for not being clear. I will
try to restate what I want to achieve. For the sake of this discussion
allow me to simplify the browser/internet interaction as follows:
User enters URL in browser - **browser resolves domain name** -
connect to server x - HTTP request
In the way the browser **resolves** the DNS is where the pac file is
used.
You may want to read and understand the specification first. Remember
that browsers do not reconfigure each time a page is hit - they obtain
the configuration once (via a direct URL to a .pac, a DHCP response, or
a DNS lookup for a wpad hostname - it's in the spec).
The only time in those activities that apache could be involved is in
the direct URL to a .pac file - and it's a static .pac file you drop on
the web server, or serve the proxy.dat file that the DHCP specified or
the DNS method is trying to find. In any way, nothing according to
apache is occurring that is dynamic - it's just serving a .pac or .dat
file.
Which means there is no need to set up an apache module that handles
stuff like this unless you are really crazy and want to construct a
dynamically generated .pac/.dat file (I would not suggest this).
If that is the direction you want to go, we may be able to assist -
however, I doubt that is what you want. Most proxy servers have static
IP addresses, which means the .pac/.dat file should be static as well.
Once again, may apologies to those who are expecting module development
assistance in this as we're not sure we even need it yet.
Joe
--
Joseph Lewis http://sharktooth.org/
Divide the fire, and you will sooner put it out. - Publius Syrus
Are you trying to make Apache follow the same rules as the browser when
it proxies (as in a proxy that uses a proxy), or just trying to set it
up? (as in double proxy)?
Joe
--
Joseph Lewis http://sharktooth.org/
Divide the fire, and you will sooner put it out. - Publius Syrus
Re: mod_proxy chaining with a .pac file
On Jan 23, 2008 6:27 PM, Ralf Mattes [EMAIL PROTECTED] wrote: On Wed, 2008-01-23 at 11:12 -0700, Joe Lewis wrote: Giovanni Donelli wrote: I am trying to make Apache follow the same rules as the browser Realize that the browser doesn't get the configurations for each website it visits, it only configures, then runs using the same configuration for every website. Realize that, since a .pac file is a ECMA-Script program, that configuration can (and often will) be dynamic. The proxy needs to be determined for each request. That means it should be easy to create a simple module that has a single configuration directive that points to the next proxy in the chain, something like WPADConfiguration http://secondproxyserver.example.com/my-proxy-file.pac And then just configure mod_proxy, mod_proxy_http, and create a handler that prefaces all URL's with the proxy: string, set the proxyreq setting in the request_rec to an appropriate value, and return 1 to allow mod_proxy to handle the rest of it. No - that's too simple. The module needs to run the JS function for each request and has to be able to dynamically set the proxy. Cheers, RalfD Thanks RalfD. You got exactly the point.
Re: mod_proxy chaining with a .pac file
Are you talking about a JS lib or a code that does what I need, support for .pac proxy chaning? As with regards with JS I was going to use the WebKit's JavaScriptCore. There _IS_ a library (C and python(?) interface) - downloadable from the google code link posted in the first message ... trivial to link into an Apache module. AFAIK it uses the mozilla JS code. Cheers, RalfD Joe
Re: Get the actual socket of a request_rec
Hi! I totally understand your concerns regarding working directly with
the socket file descriptor.
However the module I am working on needs to cooperate with an extension in
the kernel and I would like to pass small data from the kernel to the module
by using the getsockopt API.
As soon as you have have the source code with you please post it here!
Thank you very much!
Giovanni
On Nov 29, 2007 10:32 AM, bronto [EMAIL PROTECTED] wrote:
Hello,
I don't have access o my source code right now, but the mentioned method
is not one that I used (and mine worked).
I guess, in a day or two I will be able to get to my source, and send it
here.
But to mention, are you sure you need the socket file descriptor? Since
the api is done the way, that maybe 90% of modules actually don't need
to know the socket(and use bucketsbrigades). There *are* situations
though, but think about it twice.
Regards,
Stefan
Giovanni Donelli wrote / napísal(a):
I needed to:
#define CORE_PRIVATE
Sorry about that.
Anyway, this doesn't seem to be working. I'm logging the file
descriptor of different request_rec and the result is always the same,
(this can't be, right?).
Any other way to get the actual socket of a request_rec ?
Thanks!
On Nov 22, 2007 4:10 PM, Giovanni Donelli [EMAIL PROTECTED]
wrote:
Thank you very much,
what is the core_module symbol referencing to? I can't compile
it without binding that to something.
Giovanni
On Nov 22, 2007 4:05 PM, Tamas Palagyi [EMAIL PROTECTED] wrote:
Try this:
struct apr_socket_t_internal {
apr_pool_t *pool;
int socketdes;
};
int getfd(request_rec *r) {
conn_rec *c = r-connection;
apr_socket_t *s = ap_get_module_config(c-conn_config,core_module);
struct apr_socket_t_internal *i = (struct apr_socket_t_internal *)
s;
return i-socketdes;
}
I have seen somewhere some other way to get fd tough...
Tamas
On Thu, 2007-11-22 at 15:44 +, Giovanni Donelli wrote:
Dear fellow module developer,
given a request_rec*r is there anyway to get to the actual
socket
file descriptor from which the request came in?
I have been struggling all day trying to get this info out of a
request_rec. Please help!
Thank you!
Giovanni
Get the actual socket of a request_rec
Dear fellow module developer, given a request_rec*r is there anyway to get to the actual socket file descriptor from which the request came in? I have been struggling all day trying to get this info out of a request_rec. Please help! Thank you! Giovanni
Re: Get the actual socket of a request_rec
I needed to:
#define CORE_PRIVATE
Sorry about that.
Anyway, this doesn't seem to be working. I'm logging the file
descriptor of different request_rec and the result is always the same,
(this can't be, right?).
Any other way to get the actual socket of a request_rec ?
Thanks!
On Nov 22, 2007 4:10 PM, Giovanni Donelli [EMAIL PROTECTED] wrote:
Thank you very much,
what is the core_module symbol referencing to? I can't compile
it without binding that to something.
Giovanni
On Nov 22, 2007 4:05 PM, Tamas Palagyi [EMAIL PROTECTED] wrote:
Try this:
struct apr_socket_t_internal {
apr_pool_t *pool;
int socketdes;
};
int getfd(request_rec *r) {
conn_rec *c = r-connection;
apr_socket_t *s = ap_get_module_config(c-conn_config,core_module);
struct apr_socket_t_internal *i = (struct apr_socket_t_internal *) s;
return i-socketdes;
}
I have seen somewhere some other way to get fd tough...
Tamas
On Thu, 2007-11-22 at 15:44 +, Giovanni Donelli wrote:
Dear fellow module developer,
given a request_rec*r is there anyway to get to the actual socket
file descriptor from which the request came in?
I have been struggling all day trying to get this info out of a
request_rec. Please help!
Thank you!
Giovanni
Re: Get the actual socket of a request_rec
Thank you very much,
what is the core_module symbol referencing to? I can't compile
it without binding that to something.
Giovanni
On Nov 22, 2007 4:05 PM, Tamas Palagyi [EMAIL PROTECTED] wrote:
Try this:
struct apr_socket_t_internal {
apr_pool_t *pool;
int socketdes;
};
int getfd(request_rec *r) {
conn_rec *c = r-connection;
apr_socket_t *s = ap_get_module_config(c-conn_config,core_module);
struct apr_socket_t_internal *i = (struct apr_socket_t_internal *) s;
return i-socketdes;
}
I have seen somewhere some other way to get fd tough...
Tamas
On Thu, 2007-11-22 at 15:44 +, Giovanni Donelli wrote:
Dear fellow module developer,
given a request_rec*r is there anyway to get to the actual socket
file descriptor from which the request came in?
I have been struggling all day trying to get this info out of a
request_rec. Please help!
Thank you!
Giovanni
