Modify the body of a post request Multipar/form-data?
Hi, I have a Firefox module that encrypts the body content for a POST and GET request. The apache module must decrypt the content and send a crypted reply to the client. So, in my apache module, i have a filter to modify the body. For a POST x-www-form-urlencoded, the content is decrypt but in case of multipart the content is decrypted too late, the mod php has already tried to process the content. So I add a handler to my module and i get the data before php, so I decrypt the content but I can't inject the uncrypted data in the request. How modify (decrypt data) the body content before all module ? Regards, Eddy
Re: Modify the body of a post request Multipar/form-data?
On 10 Jun 2010, at 07:34, Eddy wrote: How modify (decrypt data) the body content before all module ? That's what filters do. See mod_ssl for secure encryption. Or in your case since it's only the body content, see for example mod_deflate for a comparable task. -- Nick Kew
Re: Modify the body of a post request Multipar/form-data?
For illustrate my problem : I have register a filter like in deflate : ap_register_input_filter(PerseusFilterName,perseus_in_filter, NULL, AP_FTYPE_CONTENT_SET); In httpd.conf : SetInputFilter PERSEUS So, I test with a crypted content and i hae in error.log : Perseus handler, Perseus header found : pcc [Thu Jun 10 11:29:28 2010] [error] [client 127.0.0.1] PHP Warning: Missing boundary in multipart/form-data POS T data in Unknown on line 0, referer: http://localhost/ Input Filter begin The handler do nothing, then php processes the encrypted content and fails. Then, my Filter begin and decrypt the data but it's too late. May-be I forget something, i don't understand the problem. For the deflate module, just set SetInputFilter Deflate in httpd.conf enought? Eddy On Thu, Jun 10, 2010 at 10:54 AM, Eddy eddy.deli...@gmail.com wrote: Yes i try to do the same thing but I have a problem, my filter begins too late and php has already process the data. I must do a error somewhere. Thanks for your help. Eddy On Thu, Jun 10, 2010 at 10:29 AM, Nick Kew n...@apache.org wrote: On 10 Jun 2010, at 07:34, Eddy wrote: How modify (decrypt data) the body content before all module ? That's what filters do. See mod_ssl for secure encryption. Or in your case since it's only the body content, see for example mod_deflate for a comparable task. -- Nick Kew
Re: svn commit: r951893 - in /httpd/httpd/trunk: configure.in include/ap_mmn.h include/http_config.h include/http_log.h include/httpd.h server/config.c server/core.c server/log.c server/util_debug.c
On 06/09/2010 10:00 PM, Stefan Fritsch wrote:
On Wed, 9 Jun 2010, Ruediger Pluem wrote:
+#if __STDC_VERSION__ = 199901L defined(APLOG_MAX_LOGLEVEL)
+/* need additional step to expand APLOG_MARK first */
+#define ap_log_perror(...) ap_log_perror__(__VA_ARGS__)
+#define ap_log_perror__(file, line, mi, level, status, p,
...)\
+do { if ((level) = APLOG_MAX_LOGLEVEL
) \
+ ap_do_log_perror(file, line, mi, level, status,
p, \
+ __VA_ARGS__); } while(0)
+#else
+#define ap_log_perror ap_log_perror_
+#endif
+AP_DECLARE(void) ap_log_perror_(const char *file, int line, int
module_index,
+int level, apr_status_t status,
apr_pool_t *p,
+const char *fmt, ...)
+ __attribute__((format(printf,7,8)));
I am still confused then.
Why having AP_DECLARE(void) ap_log_perror_ then?
Why define ap_log_perror to ap_log_perror_ on non C99 compilers then?
ap_do_log_perror only shows up in the definition of ap_log_perror__
nowhere else.
What does it do?
It allows (with C99 compilers) to remove debug/trace logging at compile
time by defining APLOG_MAX_LOGLEVEL. The other ap_log_*error functions
allow the same.
Sorry for be a PITN, but if APLOG_MAX_LOGLEVEL is defined on a C99 environment
this results is the following:
config.c: In function 'ap_process_config_tree':
config.c:1871: warning: implicit declaration of function 'ap_do_log_perror'
log.c: In function 'ap_log_pid':
log.c:892: warning: implicit declaration of function 'ap_do_log_perror'
util.c: In function 'ap_get_local_host':
util.c:2009: warning: implicit declaration of function 'ap_do_log_perror'
listen.c: In function 'make_sock':
listen.c:57: warning: implicit declaration of function 'ap_do_log_perror'
core.c: In function 'set_document_root':
core.c:1215: warning: implicit declaration of function 'ap_do_log_perror'
mod_so.c: In function 'load_module':
mod_so.c:186: warning: implicit declaration of function 'ap_do_log_perror'
http_protocol.c: In function 'ap_method_register':
http_protocol.c:500: warning: implicit declaration of function
'ap_do_log_perror'
server/.libs/libmain.a(log.o): In function `ap_log_pid':
/usr/src/apache/httpd-trunk/server/log.c:892: undefined reference to
`ap_do_log_perror'
server/.libs/libmain.a(listen.o): In function `alloc_listener':
/usr/src/apache/httpd-trunk/server/listen.c:284: undefined reference to
`ap_do_log_perror'
/usr/src/apache/httpd-trunk/server/listen.c:322: undefined reference to
`ap_do_log_perror'
server/.libs/libmain.a(listen.o): In function `ap_apply_accept_filter':
/usr/src/apache/httpd-trunk/server/listen.c:225: undefined reference to
`ap_do_log_perror'
server/.libs/libmain.a(listen.o): In function `make_sock':
/usr/src/apache/httpd-trunk/server/listen.c:57: undefined reference to
`ap_do_log_perror'
server/.libs/libmain.a(listen.o):/usr/src/apache/httpd-trunk/server/listen.c:67:
more undefined references to
`ap_do_log_perror' follow
collect2: ld returned 1 exit status
make[1]: *** [httpd] Fehler 1
make: *** [all-recursive] Fehler 1
Regards
Rüdiger
Authentication of proxy over own module
Hello apache users,
I would like to explain my problem.
I have developed the module which is used for authorization to web pages.
It works fine without problem but I would like to use that module for
authorization
of proxy requests as well.
Proxy requests are not defined in settings of browser (in Firefox
Tools-Options-LAN settings - Manual configuration of proxy).
In apache conf. file I have following:
VirtualHost _default_:443
SSLEngine on
SSLProxyEngine on
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
RewriteMap foo txt:/opt/apache/conf/foo.map
RewriteRule ^/PAC$ http://192.168.0.23:8080/PACAdmin [P]
RewriteRule ^/PAC/(.*) http://192.168.0.23:8080/PACAdmin/$1 [P]
RewriteRule ^/([^/]+)$ ${foo:$1|/$1} [L]
RewriteRule ^/([^/]+)/(.*) ${foo:$1|/opt/apache/htdocs/ssldocs/$1}/$2
[L]
IfModule mod_authz_host.c
Directory /
Options +Indexes +Multiviews
AuthType FOOM
require valid-user
satisfy Any
/Directory
/IfModule
Location /PAC/
ProxyPass http://192.168.0.23:8080/PACAdmin
ProxyPassReverse http://192.168.0.23:8080/PACAdmin
ProxyPassReverseCookie /PACAdmin /PAC
Order Allow,deny
Allow from all
/Location
How I can used own module for authorization location /PAC/?
When user will enter URL http://192.168.0.23:8080/PAC
then firstly my own module will authorized that page and afterwards location
/PAC will be shown.
Is it possible to do it somehow?
Thanks for your help.
--
Best Regards / S pozdravem
Petr Hracek
type_checker
Dear apache users, sorry for bother you with this question but I have a little problem with multilanguage support in FF or IE. My module does not handler like type_checker yet. in the configuration file of Apache2 I have following: AddLanguage en .en_US AddLanguage en-us .en_US AddLanguage en-gb .en_GB AddLanguage de .de AddLanguage de-at .de AddLanguage de-DE .de AddLanguage pt-br .pt_BR AddLanguage pt .pt AddLanguage es .es AddLanguage fr .fr AddLanguage it .it AddLanguage nl .nl LanguagePriority en-us en en-gb de fr it es nl pt On the system I have only HTML pages like index.en_US and index.de, foo.en_US and foo.de FIRST CASE: Unfortunatelly when in the browser I set two languages first de-at second en-us then page is always shown in English language. SECOND CASE: When browser is so that languages are: first de-at second de third en_us then page is always shown in German language. How I should implement type_checker in my module which will modify request so that in FIRST CASE will work correctly. Thank you in advance -- Best Regards / S pozdravem Petr Hracek
Re: svn commit: r951893 - in /httpd/httpd/trunk: configure.in include/ap_mmn.h include/http_config.h include/http_log.h include/httpd.h server/config.c server/core.c server/log.c server/util_debug.c
On 10.06.2010 08:09, Ruediger Pluem wrote:
On 06/09/2010 10:00 PM, Stefan Fritsch wrote:
On Wed, 9 Jun 2010, Ruediger Pluem wrote:
+#if __STDC_VERSION__= 199901L defined(APLOG_MAX_LOGLEVEL)
+/* need additional step to expand APLOG_MARK first */
+#define ap_log_perror(...) ap_log_perror__(__VA_ARGS__)
+#define ap_log_perror__(file, line, mi, level, status, p,
...)\
+do { if ((level)= APLOG_MAX_LOGLEVEL
) \
+ ap_do_log_perror(file, line, mi, level, status,
p, \
+ __VA_ARGS__); } while(0)
+#else
+#define ap_log_perror ap_log_perror_
+#endif
+AP_DECLARE(void) ap_log_perror_(const char *file, int line, int
module_index,
+int level, apr_status_t status,
apr_pool_t *p,
+const char *fmt, ...)
+ __attribute__((format(printf,7,8)));
I am still confused then.
Why having AP_DECLARE(void) ap_log_perror_ then?
Why define ap_log_perror to ap_log_perror_ on non C99 compilers then?
ap_do_log_perror only shows up in the definition of ap_log_perror__
nowhere else.
What does it do?
It allows (with C99 compilers) to remove debug/trace logging at compile
time by defining APLOG_MAX_LOGLEVEL. The other ap_log_*error functions
allow the same.
Sorry for be a PITN, but if APLOG_MAX_LOGLEVEL is defined on a C99 environment
this results is the following:
config.c: In function 'ap_process_config_tree':
config.c:1871: warning: implicit declaration of function 'ap_do_log_perror'
log.c: In function 'ap_log_pid':
log.c:892: warning: implicit declaration of function 'ap_do_log_perror'
util.c: In function 'ap_get_local_host':
util.c:2009: warning: implicit declaration of function 'ap_do_log_perror'
listen.c: In function 'make_sock':
listen.c:57: warning: implicit declaration of function 'ap_do_log_perror'
core.c: In function 'set_document_root':
core.c:1215: warning: implicit declaration of function 'ap_do_log_perror'
mod_so.c: In function 'load_module':
mod_so.c:186: warning: implicit declaration of function 'ap_do_log_perror'
http_protocol.c: In function 'ap_method_register':
http_protocol.c:500: warning: implicit declaration of function
'ap_do_log_perror'
server/.libs/libmain.a(log.o): In function `ap_log_pid':
/usr/src/apache/httpd-trunk/server/log.c:892: undefined reference to
`ap_do_log_perror'
server/.libs/libmain.a(listen.o): In function `alloc_listener':
/usr/src/apache/httpd-trunk/server/listen.c:284: undefined reference to
`ap_do_log_perror'
/usr/src/apache/httpd-trunk/server/listen.c:322: undefined reference to
`ap_do_log_perror'
server/.libs/libmain.a(listen.o): In function `ap_apply_accept_filter':
/usr/src/apache/httpd-trunk/server/listen.c:225: undefined reference to
`ap_do_log_perror'
server/.libs/libmain.a(listen.o): In function `make_sock':
/usr/src/apache/httpd-trunk/server/listen.c:57: undefined reference to
`ap_do_log_perror'
server/.libs/libmain.a(listen.o):/usr/src/apache/httpd-trunk/server/listen.c:67:
more undefined references to
`ap_do_log_perror' follow
collect2: ld returned 1 exit status
make[1]: *** [httpd] Fehler 1
make: *** [all-recursive] Fehler 1
Fixed and tested (r953248).
Rainer
Re: type_checker
On 10 Jun 2010, at 09:37, Petr Hracek wrote: Dear apache users, This is the developers list. Users are us...@. My module does not handler like type_checker yet. Your module? As opposed to mod_negotiation? How I should implement type_checker in my module which will modify request so that in FIRST CASE will work correctly. See the content negotiation docs. And check your spelling. -- Nick Kew
Re: type_checker
Could you please help me what spelling is wrong? I want to add type_checker to my module as last step of course if there will be no other option. 2010/6/10 Nick Kew n...@webthing.com On 10 Jun 2010, at 09:37, Petr Hracek wrote: Dear apache users, This is the developers list. Users are us...@. My module does not handler like type_checker yet. Your module? As opposed to mod_negotiation? How I should implement type_checker in my module which will modify request so that in FIRST CASE will work correctly. See the content negotiation docs. And check your spelling. -- Nick Kew -- Best Regards / S pozdravem Petr Hracek
Re: mod_socache_shmcb bogosity?
On Wed, Jun 09, 2010 at 11:30:45AM -0500, William Rowe wrote: Just noticed that our shmcb socache never replaces an identical node on -store, leading to multiple entries for the same id (with different expiries and data, obviously). Is this deliberate? What is the distcache/memcached/dbm behavior, are they all replacing the existing node? What is the programming contract? It's a cyclic buffer - the most recently stored entry should be returned by a retrieve operation... the old entry should effectively be invisible to the caller. Is that not working? w.r.t. contract: specific behaviour will vary across the providers; could nail down the -retrieve API with a bunch of stuff which is *not* guaranteed, I suppose, is that what you're thinking of? object returned may be out-of-date/stale, etc Regards, Joe
Re: Alpha of 2.3.6 next week
Okey dokey... unless I hear otherwise w/i a few hours, I will tag and roll 2.3.6-alpha On Jun 8, 2010, at 4:25 PM, Mario Brandt wrote: Thanks Stefan, it builds fine. Mario On Tue, Jun 8, 2010 at 21:51, Stefan Fritsch s...@sfritsch.de wrote: This should be fixed now and I hopefully have also addressed Bill's concern about r952724. I don't see any blocker for an alpha-release anymore.
Re: Alpha of 2.3.6 next week
And with a few addt'l patches, it builds clean (excluding some recent ldap oddities coming from MS's toolchain), thanks for taking a good look into this Mario. On 6/8/2010 3:25 PM, Mario Brandt wrote: Thanks Stefan, it builds fine. Mario On Tue, Jun 8, 2010 at 21:51, Stefan Fritsch s...@sfritsch.de wrote: This should be fixed now and I hopefully have also addressed Bill's concern about r952724. I don't see any blocker for an alpha-release anymore.
Re: Alpha of 2.3.6 next week
FWIW, I'm holding off based on a proxy/closing connection issue... On Jun 10, 2010, at 8:47 AM, Jim Jagielski wrote: Okey dokey... unless I hear otherwise w/i a few hours, I will tag and roll 2.3.6-alpha On Jun 8, 2010, at 4:25 PM, Mario Brandt wrote: Thanks Stefan, it builds fine. Mario On Tue, Jun 8, 2010 at 21:51, Stefan Fritsch s...@sfritsch.de wrote: This should be fixed now and I hopefully have also addressed Bill's concern about r952724. I don't see any blocker for an alpha-release anymore.
Re: Module build defaults for trunk
On Monday 07 June 2010, Rainer Jung wrote: - build most module set by default. Alternatives are: - all - few (same set as was default before the change) - none I would like to have an option for developers/testers that builds every module that can be built with the currently installed libraries. The attached patch adds a reallyall set. My auto-fu could be better but the patch works for me (tm). Of course, I am open for better names than reallyall. The patch also removes the --enable-distcache option. If the user requested mod_socache_dc we already know he wants distcache. No need for a special option (unless it allowed to select the prefix, which it didn't). And it also makes the --with-serf option default to /usr. Same reasoning: If the user requested mod_serf, he wants --with-serf. diff --git a/acinclude.m4 b/acinclude.m4 index 6f7fe74..e49ac78 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -282,7 +282,8 @@ AC_DEFUN(APACHE_MODULE,[ _apmod_extra_msg= dnl When --enable-modules=most is set and the module was not explicitly dnl requested, allow a module to disable itself if its pre-reqs fail. - if test $module_selection = most -a $enable_$1 = most; then + if test $module_selection = most -a $enable_$1 = most || + test $module_selection = reallyall; then _apmod_error_fatal=no else _apmod_error_fatal=yes @@ -292,19 +293,21 @@ AC_DEFUN(APACHE_MODULE,[ elif test $enable_$1 = yes; then enable_$1=$module_default elif test $enable_$1 = most; then -if test $module_selection = most -o $module_selection = all; then +if test $module_selection = most -o $module_selection = all -o $module_selection = reallyall; then enable_$1=$module_default elif test $module_selection = few -o $module_selection = none; then enable_$1=no fi _apmod_extra_msg= ($module_selection) elif test $enable_$1 = maybe-all; then -if test $module_selection = all; then +if test $module_selection = all -o $module_selection = reallyall; then enable_$1=$module_default _apmod_extra_msg= (all) else enable_$1=no fi + elif test $enable_$1 = no -a $module_selection = reallyall; then + enable_$1=$module_default fi if test $enable_$1 != no; then dnl If we plan to enable it, allow the module to run some autoconf magic @@ -361,14 +364,15 @@ AC_DEFUN(APACHE_ENABLE_MODULES,[ AC_ARG_ENABLE(modules, - APACHE_HELP_STRING(--enable-modules=MODULE-LIST,Space-separated list of modules to enable | all | most | few | none),[ + APACHE_HELP_STRING(--enable-modules=MODULE-LIST,Space-separated list of modules to enable | all | most | few | none| reallyall),[ if test $enableval = none; then module_default=no module_selection=none else for i in $enableval; do -if test $i = all -o $i = most -o $i = few; then +if test $i = all -o $i = most -o $i = few -o $i = reallyall; then module_selection=$i + echo module_selection: $module_selection else i=`echo $i | sed 's/-/_/g'` eval enable_$i=shared @@ -378,9 +382,9 @@ AC_DEFUN(APACHE_ENABLE_MODULES,[ ]) AC_ARG_ENABLE(mods-shared, - APACHE_HELP_STRING(--enable-mods-shared=MODULE-LIST,Space-separated list of shared modules to enable | all | most | few),[ + APACHE_HELP_STRING(--enable-mods-shared=MODULE-LIST,Space-separated list of shared modules to enable | all | most | few| reallyall),[ for i in $enableval; do - if test $i = all -o $i = most -o $i = few; then + if test $i = all -o $i = most -o $i = few -o $i = reallyall; then module_selection=$i module_default=shared else diff --git a/modules/cache/config.m4 b/modules/cache/config.m4 index a750b96..f2461ce 100644 --- a/modules/cache/config.m4 +++ b/modules/cache/config.m4 @@ -16,43 +16,11 @@ APACHE_MODULE(cache, dynamic file caching, $cache_objs, , most) APACHE_MODULE(disk_cache, disk caching module, , , most) AC_DEFUN([CHECK_DISTCACHE], [ - AC_MSG_CHECKING(whether Distcache is required) - ap_ssltk_dc=no - tmp_nomessage= - tmp_forced=no - AC_ARG_ENABLE(distcache, -APACHE_HELP_STRING(--enable-distcache,Enable distcache support), -ap_ssltk_dc=$enableval -tmp_nomessage= -tmp_forced=yes -if test x$ap_ssltk_dc = x; then - ap_ssltk_dc=yes - dnl our errors become tests revealed that... - tmp_forced=no -fi -if test $ap_ssltk_dc != yes -a $ap_ssltk_dc != no; then - tmp_nomessage=--enable-distcache had illegal syntax - disabling - ap_ssltk_dc=no -fi) - if test $tmp_forced = no; then -AC_MSG_RESULT($ap_ssltk_dc (default)) - else -AC_MSG_RESULT($ap_ssltk_dc (specified)) - fi - if test $tmp_forced = yes -a x$ap_ssltk_dc = xno -a x$tmp_nomessage != x; then -AC_MSG_ERROR(distcache support failed: $tmp_nomessage) - fi - if test $ap_ssltk_dc = yes; then -AC_CHECK_HEADER( - [distcache/dc_client.h], -
Re: mod_socache_shmcb bogosity?
On 6/10/2010 7:15 AM, Joe Orton wrote: On Wed, Jun 09, 2010 at 11:30:45AM -0500, William Rowe wrote: Just noticed that our shmcb socache never replaces an identical node on -store, leading to multiple entries for the same id (with different expiries and data, obviously). Is this deliberate? What is the distcache/memcached/dbm behavior, are they all replacing the existing node? What is the programming contract? It's a cyclic buffer - the most recently stored entry should be returned by a retrieve operation... the old entry should effectively be invisible to the caller. Is that not working? Have not checked specifically, the problem I observed was ejecting other unexpired elts as other records were repeatedly updated. It seems the simple fix is to change the pre-store free logic, * expire records [do this only if space needed? right now, it's on all stores] * if enospace, compress removed/expired records until space is available * if still enospace, drop the first-to-expire [current behavior] Seem sensible? w.r.t. contract: specific behaviour will vary across the providers; could nail down the -retrieve API with a bunch of stuff which is *not* guaranteed, I suppose, is that what you're thinking of? object returned may be out-of-date/stale, etc If we know it may be stale, we should declare that (in the shmcb case, this never happens, IIRC). We obviously should declare this is a lossy cache. In other events, the current logic of max 256 caches keyed on the first byte of ID is not sufficiently resuable. What do folks suggest for the most efficient hash method? I'm thinking we add to the hints that hashing is required, or assuring that the data is 8-bit hashed already and leading bytes are just fine for choosing subcaches. In order to achieve the goal above of compressing records, it would seem sensible to favor more subcaches with no more than 64k worth of elts, which ensures any compressing memcpy's are more efficient.
