Re: Question and request for comments on patch
> > I attempted to commit this, but ran into the following error. This is my > first try to commit, so I very well may be doing something wrong. I'm > attempting from my machine here at home rather than minotaur. Any > suggestions? > > svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk you have to check out as, or switch to, https to commit. I believe "svn switch --relocate http://... https://..."; is close.
Re: Question and request for comments on patch
On 7/26/2011 5:02 AM, Stefan Fritsch wrote: > This is valid use-case which justifies making it available somehow. > But actually, I think something like > > module *mod = &ap_top_module; > ap_find_command_in_modules(cmd, mod); > > should already work without the need for an additional API. This way > is not very efficient but as this is only done on server startup, > that's not important. On 7/26/2011 5:35 AM, "Plüm, Rüdiger, VF-Group" wrote: > IMHO the keys in apr_tables are case insensitive. So this tolower shouldn't > be needed. Both points taken and implemented. Regarding invalid directives, I set it as a warning informing that the directive is being discarded. I never actually tested apr_tables to see if they were case sensitive but had assumed they were. The offending lines of code have been removed. Thank you, guys. I attempted to commit this, but ran into the following error. This is my first try to commit, so I very well may be doing something wrong. I'm attempting from my machine here at home rather than minotaur. Any suggestions? svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk httpd-trunk && cd http-trunk svn changelist httpd-trunk.AllowOverrideList docs/manual/developer/new_api_2_4.xml docs/manual/mod/core.xml server/config.c server/core.c server/request.c include/http_config.h include/ap_mmn.h include/httpd.h include/http_core.h ... svn commit --username druggeri --password REDACTED --message "Add AllowOverrideList directive and documentation" --changelist httpd-trunk.AllowOverrideList svn: Commit failed (details follow): svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/repos/asf/!svn/act/2f9005f7-2cd2-4c3f-9311-77bdcf4322e2' User credentials to svn.apache.org web interface and people.apache.org work fine so I suspect there's more to the equation. -- -- Daniel Ruggeri
Re: [NOTICE] Intent to T&R httpd 2.3.14
No, but this is not a regression from any prior version (AcceptFilter issue), I just tested on 2.3.5 and the issue is there. I don't see this as holding up another Beta should folks want one. It surely needs to addressed asap before GA. Gregg On 7/25/2011 8:03 AM, Steffen wrote: Reported Windows issue fixed ? - Original Message - From: "Jim Jagielski" To: Sent: Monday, July 25, 2011 4:49 PM Subject: [NOTICE] Intent to T&R httpd 2.3.14 Just a heads up that my plan is to T&R httpd 2.3.14 later on this week (like Thursday), now that the LDAP issues have been reverted. Let's polish up trunk and rebuild the momentum to 2.4.0!
Authentication and ReverseProxy to more servers
Dear developers,
sorry for bother you with that question but I could not imagine where
I have made a problem?
Situation have to be following:
I have MAIN server connected to the intranet. To that MAIN server are
connected some other servers.
In the MAIN server is buildup proprietary authentication module which
is used for authorization and authentication.
When the user write down in URL somethink like:
https:///application1 then this should be reversed
proxied to the http://192.168.0.20:8080/appl1
https:///application2 then this should be reversed
proxied to the http://192.168.0.30:8080/appl2
Both applications like application1 and application2 have to be
authorized first in the MAIN server and than proxied to
the relevant servers.
Authentication works fine but it is not proxied.
In the /var/log/apache2/error_log file is not mentioned and log from
mod_proxy.c module
and ReverseProxy is not working at all.
In the log is mentioned only:
File does not exists: /srv/www/htdocs/ssldocs/application1
But this is true because of it has to be proxied.
Handlers in my modules are:
static void register_hooks(apr_pool_t * p)
{
static const char * const
aszPre[]={"mod_proxy.c","mod_proxy_http.c","mod_proxy_ajp.c",NULL};
ap_hook_auth_checker(access_handler,NULL,NULL,APR_HOOK_FIRST);
ap_hook_check_user_id(auth_handler,NULL,NULL,APR_HOOK_FIRST);
}
Should be there add ap_hook_map_to_storage?
Could you please let me know how to do it?
Configuration file in MAIN server looks like:
DocumentRoot "/srv/www/htdocs/ssldocs"
SSLEngine on
SSLProxyEngine on
ProxyRequests Off
AuthType OwnSec
require valid-user
Order Allow,deny
Allow from all
ProxyPass /application1 http://192.168.0.20:8080/appl1
ProxyPassReverse /application1 http://192.168.0.20:8080/appl1
ProxyPass /application2 http://192.168.0.30:8080/appl1
ProxyPassReverse /application2 http://192.168.0.30:8080/appl2
--
Best Regards / S pozdravem
Petr Hracek
RE: Question and request for comments on patch
> -Original Message- > From: Daniel Ruggeri > Sent: Montag, 25. Juli 2011 01:36 > To: dev@httpd.apache.org > Subject: Re: Question and request for comments on patch > and unavailable to core.c where the configuration directive is > implemented? If I'm off, I'd definitely like to add this as well as > remove the need for the 'tolower' calls by looking up the expected > CamelCase of a directive as it shows up in config.c. IMHO the keys in apr_tables are case insensitive. So this tolower shouldn't be needed. Regards Rüdiger
Re: Question and request for comments on patch
On Monday 25 July 2011, Daniel Ruggeri wrote: > On 7/24/2011 2:12 AM, Stefan Fritsch wrote: > > When parsing the list, look in ap_config_hash if a directive > > exists. If not, either log a warning or error out (not sure > > which is better). > > I may be missing something, but isn't ap_config_hash private to > config.c and unavailable to core.c where the configuration > directive is implemented? If I'm off, I'd definitely like to add > this as well as remove the need for the 'tolower' calls by looking > up the expected CamelCase of a directive as it shows up in > config.c. This is valid use-case which justifies making it available somehow. But actually, I think something like module *mod = &ap_top_module; ap_find_command_in_modules(cmd, mod); should already work without the need for an additional API. This way is not very efficient but as this is only done on server startup, that's not important. > > It should be possible to reset AllowOverrideList to an empty list > > in a subdir, even if it is set in the parent dir. This is > > important in the case that there is a permissive > > AllowOverrideList in main server scope and an empty one for some > > virtual hosts. In the case of an empty list, d->override_list > > should be set to NULL instead of an empty table for better > > performance. Maybe one could allow "disabled" or "reset" as > > alias for an empty list (like in UserDir/DirectoryIndex). > > I realized I did not add this about five minutes after sending the > patch along to the list. I have added this also. Your followup > email about making the list NULL complicating things is also true > - I had a lot of trouble merging properly when NULL was considered > "nothing in the list" as opposed to "not configured". htaccess parsing is notoriously slow anyway. One more table lookup won't hurt that much, so IMHO no need to complicate things here. > > It may be possible that some modules react badly if a directive > > is used in .htaccess that has previously not been allowed there. > > For example if the module needs to do some global initialization > > when a directive is used for the first time. I am not aware of > > such a case, but it is something we may want to keep in mind if > > this is backported. And it is definitely something that should > > go into the new_api_2.4 document. > > Yes, very good point - I did not realize this would become a side > effect. I thought there were upstream context checks before a > command is invoked to prevent this. > I have taken the second suggestion and added a note in > new_api_2.4.xml also. Maybe we want to extend ap_check_cmd_context() to have something like NOT_IN_HTACCESS. In any case, I think your patch is good enough for the next beta. We can solve any remaining issues before GA. Cheers, Stefan
