substitute not working
Hello,
I came not on done after much wasting time.
I would use SSI, but it did not work.
The directives in the config will not parsed.
Neither php, shtml, or else.
# here a snippet of my apache2.conf
User www-data
Group www-data
LoadModule auth_basic_module mod/mod_auth_basic.so
LoadModule authn_file_module mod/mod_authn_file.so
LoadModule authz_core_module mod/mod_authz_core.so
LoadModule authz_host_module mod/mod_authz_host.so
LoadModule authz_user_module mod/mod_authz_user.so
LoadModule authz_groupfile_module mod/mod_authz_groupfile.so
LoadModule include_module mod/mod_include.so
LoadModule alias_module mod/mod_alias.so
LoadModule mime_module mod/mod_mime.so
LoadModule mime_magic_module mod/mod_mime_magic.so
LoadModule negotiation_module mod/mod_negotiation.so
LoadModule filter_module /usr/lib/apache2/modules/mod_filter.so
LoadModule dir_module mod/mod_dir.so
LoadModule substitute_module mod/mod_substitute.so
LoadModule env_module mod/mod_env.so
LoadModule autoindex_module mod/mod_autoindex.so
LoadModule cache_module mod/mod_cache.so
LoadModule proxy_module mod/mod_proxy.so
LoadModule proxy_http_module mod/mod_proxy_http.so
LoadModule headers_module mod/mod_headers.so
LoadModule deflate_module mod/mod_deflate.so
LoadModule reqtimeout_module mod/mod_reqtimeout.so
LoadModule rewrite_module mod/mod_rewrite.so
LoadModule status_module mod/mod_status.so
LoadModule ext_filter_module mod/mod_ext_filter.so
LoadModule sed_module mod/mod_sed.so
#
LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
LoadModule mpm_prefork_module /usr/lib/apache2/modules/mod_mpm_prefork.so
# and here my default vhost:
#ExtFilterDefine c-to-html mode=output \
# intype=text/c outtype=text/html \
# cmd="/http/cmd/enscript.pl"
ServerAdmin kallup.j...@web.de
ServerName localhost
# ServerAlias www.kallup.solutions
DocumentRoot "/html/public/"
AddLanguage de .de
AddLanguage en .en
LanguagePriority de en
AddDefaultCharset UTF-8
FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
FilterChain SSI
FilterDeclare gzip CONTENT_SET
FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
FilterChain gzip
# FilterDeclare filter_kallup
# FilterProvider filter_kallup SUBSTITUTE resp=Content-Type text/html
# FilterProvider filter_kallup INCLUDES resp=Content-Type text/html
# FilterChain filter_kallup SUBSTITUTE 's|||ni'
# Alias /inc/footer.html /inc/footer.php
AddType text/html shtml
AddHandler server-parsed .shtml
AddOutputFilter INCLUDES .shtml
AddOutputFilterByType SUBSTITUTE text/html
Substitute "s||Eine
Werbung|i"
Substitute "s||$_SERVER['DOCUMENT_ROOT'].'/inc/footer.html') == FALSE) { echo 'ERROR,
can't display page !!!'; die;} ?>|i"
# here, the line above (php) will not handled as php, response is
raw/plain text
# the same for
Re: Changing mod_lua to stable
On Fri, Jan 25, 2019 at 2:47 PM Chris Punches wrote: > Someone may want to add some text along the lines of when to use u/WSGI > instead of mod_lua as that's going to be a thing if this goes stable. If > the what/when isn't in there clearly we could run into really bad > situations like ASF using mod_lua to host web services in production. > As D.Gruno noted, we *already* use mod_lua in production at the ASF, and have seen zero problems with the module. Cheers, -g
Re: Changing mod_lua to stable
Someone may want to add some text along the lines of when to use u/WSGI instead of mod_lua as that's going to be a thing if this goes stable. If the what/when isn't in there clearly we could run into really bad situations like ASF using mod_lua to host web services in production. On Fri, Jan 25, 2019 at 2:36 PM Eric Covener wrote: > On Fri, Jan 25, 2019 at 2:12 PM Frank Kuhn wrote: > > > > > > > > On 12/17/18 8:23 PM, Daniel Gruno wrote: > > > Hi folks, > > > I've been pondering on the state of mod_lua, and it seems like it's > time > > > to get rid of the 'experimental' note, which still scares off a lot of > > > people. The API has been steady over the past few years, I believe, and > > > the code itself seems to be in a stable state, so I'm inclined to go > > > ahead and get it moved over to stable, including switching from CTR to > RTC. > > > [...] > > > > Hi, > > I have big problems with LuaOutputFilter and SetOutputFilter (see > > https://bz.apache.org/bugzilla/show_bug.cgi?id=62726) so I cannot call > > it 'stable'... > > Stable from an API perspective, not bug-free. The disclaimer we have > used recently for experimental is: > > > This module is experimental. Its behaviors, directives, and defaults are > subject to more change from release to release relative to other standard > modules. Users are encouraged to consult the "CHANGES" file for potential > updates. >
Re: Changing mod_lua to stable
On Fri, Jan 25, 2019 at 2:12 PM Frank Kuhn wrote: > > > > On 12/17/18 8:23 PM, Daniel Gruno wrote: > > Hi folks, > > I've been pondering on the state of mod_lua, and it seems like it's time > > to get rid of the 'experimental' note, which still scares off a lot of > > people. The API has been steady over the past few years, I believe, and > > the code itself seems to be in a stable state, so I'm inclined to go > > ahead and get it moved over to stable, including switching from CTR to RTC. > > [...] > > Hi, > I have big problems with LuaOutputFilter and SetOutputFilter (see > https://bz.apache.org/bugzilla/show_bug.cgi?id=62726) so I cannot call > it 'stable'... Stable from an API perspective, not bug-free. The disclaimer we have used recently for experimental is: > This module is experimental. Its behaviors, directives, and defaults are > subject to more change from release to release relative to other standard > modules. Users are encouraged to consult the "CHANGES" file for potential > updates.
Re: Changing mod_lua to stable
On 12/17/18 8:23 PM, Daniel Gruno wrote: Hi folks, I've been pondering on the state of mod_lua, and it seems like it's time to get rid of the 'experimental' note, which still scares off a lot of people. The API has been steady over the past few years, I believe, and the code itself seems to be in a stable state, so I'm inclined to go ahead and get it moved over to stable, including switching from CTR to RTC. [...] Hi, I have big problems with LuaOutputFilter and SetOutputFilter (see https://bz.apache.org/bugzilla/show_bug.cgi?id=62726) so I cannot call it 'stable'... Best regars, Frank. P.S.: And when I am not wrong https://bz.apache.org/bugzilla/show_bug.cgi?id=62359 also needs some work... And while looking at this someone should also look at the whole list: https://bz.apache.org/bugzilla/buglist.cgi?bug_status=__open__=mod_lua=Apache%20httpd-2
Re: Close mbox-cvs@ mailing list?
On Sun, Jan 20, 2019 at 7:02 PM sebb wrote: > The mbox-cvs@httpd used to be used for mbox commit messages. > > However these now seem to be sent to cvs@ > > AFAICT there is no need to keep the list. > > Agreed? > Right call. The same is true of apreq-cvs@httpd, the commits should be going to cvs@httpd, and the list closed. Similarly with apreq-dev@httpd, this list can be closed, since that code was adopted by dev@httpd 8 years ago. The list was alerted to this change some months ago, I just hadn't gotten back to filing an infra ticket to make it so.
Re: Close mbox-cvs@ mailing list?
Sounds sensible to shut it down. Regards Rüdiger On 01/25/2019 12:32 PM, sebb wrote: > Any comments? > > On Mon, 21 Jan 2019 at 01:02, sebb wrote: >> >> The mbox-cvs@httpd used to be used for mbox commit messages. >> >> However these now seem to be sent to cvs@ >> >> AFAICT there is no need to keep the list. >> >> Agreed? >> >> S. >
Re: Close mbox-cvs@ mailing list?
Any comments? On Mon, 21 Jan 2019 at 01:02, sebb wrote: > > The mbox-cvs@httpd used to be used for mbox commit messages. > > However these now seem to be sent to cvs@ > > AFAICT there is no need to keep the list. > > Agreed? > > S.
