RE: new ProxyPass/ProxyPassReverse feature for 2.4??
-Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Montag, 28. März 2011 21:08 To: dev@httpd.apache.org Subject: new ProxyPass/ProxyPassReverse feature for 2.4?? Assuming ProxyPass /foo http://www.example.com/foo should ProxyPass automatically create the corresponding ProxyPassReverse statement? It seems bogus to me that we still require such things... Of course, we can't get rid of it completely, to handle such cases as: ProxyPass / ajp://localhost:8009/jsp/ ProxyPassReverse / http://www.example.com/jsp/ but shouldn't we automagically handle the common case?? If this behaviour is well documented and could be turned off I am +0. I want to avoid a smart server getting in the way of an admin if the situation requires special handling. Regards Rüdiger
blocking Upgrade
Does anyone with a working install want a quick project? We need to block the Upgrade header field by default. What this will require is a new configuration command, like AllowUpgrade None | word ... where word is any protocol name, like HTTP/2.0, waka, websocket, etc. The config command must only be allowed in rsrc_conf. We then need a check somewhere in the http filter for an incoming request header field called Upgrade. If present and the config option is set to None (or default), then remove the Upgrade field before it is seen by the request handler (i.e., before it might be used by some module or CGI script to send the server down a rat hole). If the config option is set and not None, then set the Upgrade header field-value to be the intersection of what was sent by the client and what is allowed by the config. Likewise, perform the same filtering on outbound responses. In other words, only allow a handler to upgrade the connection if it has been explicitly configured by the main server config to be an okay thing to do. Any takers? If not, I'll give it a try next week when I am back from the IETF. Roy
Re: blocking Upgrade
Do you have an internet draft spec for some context here? Is there a proposal for HTTP/2.0? I might also argue that a directive is not the right answer here. Instead, I'd suggest that modules advertise their ability to consume protocols. If an Upgrade arrives, and a relevant module is found, then the request is handled. If no such module is found, then the Upgrade header is ignored, and nothing happens.˛˛ If a module or CGI sees the Upgrade header, then what is the problem? It cannot truly alter the protocol in effect for the connection. That seems to be something only possible to handle within the core (to change the connection handler). And back to the AllowUpgrade directive. What the heck should it do if something is present *besides* none. It isn't like that can be handled. Some code must be written to provide other protocols, and *that* code should manage the tokens recognized. Not a directive. Cheers, -g On Tue, Mar 29, 2011 at 17:04, Roy T. Fielding field...@gbiv.com wrote: Does anyone with a working install want a quick project? We need to block the Upgrade header field by default. What this will require is a new configuration command, like AllowUpgrade None | word ... where word is any protocol name, like HTTP/2.0, waka, websocket, etc. The config command must only be allowed in rsrc_conf. We then need a check somewhere in the http filter for an incoming request header field called Upgrade. If present and the config option is set to None (or default), then remove the Upgrade field before it is seen by the request handler (i.e., before it might be used by some module or CGI script to send the server down a rat hole). If the config option is set and not None, then set the Upgrade header field-value to be the intersection of what was sent by the client and what is allowed by the config. Likewise, perform the same filtering on outbound responses. In other words, only allow a handler to upgrade the connection if it has been explicitly configured by the main server config to be an okay thing to do. Any takers? If not, I'll give it a try next week when I am back from the IETF. Roy
Re: blocking Upgrade
On 3/29/2011 4:16 PM, Greg Stein wrote: Do you have an internet draft spec for some context here? Is there a proposal for HTTP/2.0? I might also argue that a directive is not the right answer here. Instead, I'd suggest that modules advertise their ability to consume protocols. If an Upgrade arrives, and a relevant module is found, then the request is handled. If no such module is found, then the Upgrade header is ignored, and nothing happens.˛˛ If a module or CGI sees the Upgrade header, then what is the problem? It cannot truly alter the protocol in effect for the connection. That seems to be something only possible to handle within the core (to change the connection handler). And back to the AllowUpgrade directive. What the heck should it do if something is present *besides* none. It isn't like that can be handled. Some code must be written to provide other protocols, and *that* code should manage the tokens recognized. Not a directive. Agreed, we already have a single example case; in the presence of the 'SSLEngine optional' directive, which consumes the Upgrade: TLS/1.0 given Connection: Upgrade All such handlers must respond with a 101 Switching Protocols. So if we don't see the resulting Upgrade: TLS/1.0, HTTP/1.1 response header, we can easily short circuit any further response in the core handler. The mechanics of this could be simplified, but I'd suggest we start by stealing code from mod_ssl's upgrade handler. The only remaining system administration decision is allow or refuse unrecognized Upgrade requests? The recognition of specific upgrade headers is up to the installed modules and their specific configurations.
Re: blocking Upgrade
On Mar 29, 2011 5:35 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 3/29/2011 4:16 PM, Greg Stein wrote: Do you have an internet draft spec for some context here? Is there a proposal for HTTP/2.0? I might also argue that a directive is not the right answer here. Instead, I'd suggest that modules advertise their ability to consume protocols. If an Upgrade arrives, and a relevant module is found, then the request is handled. If no such module is found, then the Upgrade header is ignored, and nothing happens.˛˛ If a module or CGI sees the Upgrade header, then what is the problem? It cannot truly alter the protocol in effect for the connection. That seems to be something only possible to handle within the core (to change the connection handler). And back to the AllowUpgrade directive. What the heck should it do if something is present *besides* none. It isn't like that can be handled. Some code must be written to provide other protocols, and *that* code should manage the tokens recognized. Not a directive. Agreed, we already have a single example case; in the presence of the 'SSLEngine optional' directive, which consumes the Upgrade: TLS/1.0 given Connection: Upgrade All such handlers must respond with a 101 Switching Protocols. So if we don't see the resulting Upgrade: TLS/1.0, HTTP/1.1 response header, we can easily short circuit any further response in the core handler. The mechanics of this could be simplified, but I'd suggest we start by stealing code from mod_ssl's upgrade handler. The only remaining system administration decision is allow or refuse unrecognized Upgrade requests? The recognition of specific upgrade headers is up to the installed modules and their specific configurations. Note that the client-sent Upgrade header can be completely disregarded by the server: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42 I'm not sure that we have anything mandatory to do here. I think the correct answer is to provide connection-layer protocol handling pass-offs. I don't see how a directive assists here. Cheers, -g
Current module imports/exports
In researching our current dependencies, I came up with the following data which a few of you would probably find interesting (based on only module-to-module dependencies from httpd trunk built on win32); MOD_ACCESS_COMPAT.SO export access_compat_module MOD_ACTIONS.SO export actions_module MOD_ALIAS.SO export alias_module MOD_ASIS.SO export asis_module MOD_AUTHNZ_LDAP.SO export authnz_ldap_module MOD_AUTHN_ANON.SO export authn_anon_module MOD_AUTHN_CORE.SO export authn_core_module MOD_AUTHN_DBD.SO export authn_dbd_module MOD_AUTHN_DBM.SO export authn_dbm_module MOD_AUTHN_FILE.SO export authn_file_module MOD_AUTHZ_CORE.SO export authz_core_module MOD_AUTHZ_DBD.SO export authz_dbd_module export authz_dbd_run_client_login MOD_AUTHZ_DBM.SO export authz_dbm_module MOD_AUTHZ_GROUPFILE.SO export authz_groupfile_module MOD_AUTHZ_HOST.SO export authz_host_module MOD_AUTHZ_OWNER.SO export authz_owner_module MOD_AUTHZ_USER.SO export authz_user_module MOD_AUTH_BASIC.SO export auth_basic_module MOD_AUTH_DIGEST.SO export auth_digest_module MOD_AUTH_FORM.SO export auth_form_module MOD_AUTOINDEX.SO export autoindex_module MOD_BUFFER.SO export buffer_module MOD_CACHE.SO export ap_cache_cacheable_headers export ap_cache_cacheable_headers_in export ap_cache_cacheable_headers_out export ap_cache_check_allowed export ap_cache_current_age export ap_cache_generate_name export ap_cache_hex2usec export ap_cache_liststr export ap_cache_tokstr MOD_CACHE_DISK.SO export cache_disk_module MOD_CACHE.SO import ap_cache_cacheable_headers_in import ap_cache_cacheable_headers_out import ap_cache_generate_name export ap_cache_cacheable_headers export ap_cache_cacheable_headers_in export ap_cache_cacheable_headers_out export ap_cache_check_allowed export ap_cache_current_age export ap_cache_generate_name export ap_cache_hex2usec export ap_cache_liststr export ap_cache_tokstr MOD_CERN_META.SO export cern_meta_module MOD_CGI.SO export cgi_module MOD_CHARSET_LITE.SO export charset_lite_module MOD_DAV.SO export dav_add_all_liveprop_xmlns export dav_add_lock export dav_add_response export dav_add_vary_header export dav_auto_checkin export dav_auto_checkout export dav_buffer_append export dav_buffer_init export dav_buffer_place export dav_do_find_liveprop export dav_find_child export dav_get_allprops export dav_get_binding_hooks export dav_get_depth export dav_get_liveprop_info export dav_get_liveprop_ns_count export dav_get_liveprop_ns_index export dav_get_liveprop_supported export dav_get_lock_hooks export dav_get_search_hooks export dav_get_timeout export dav_get_vsn_hooks export dav_hook_find_liveprop export dav_hook_gather_propsets export dav_hook_get_find_liveprop export dav_hook_get_gather_propsets export dav_hook_get_insert_all_liveprops export dav_hook_insert_all_liveprops export dav_lock_get_activelock export dav_new_error_tag export dav_notify_created export dav_open_propdb export dav_options_provider_register export dav_prop_commit export dav_prop_exec export dav_prop_rollback export dav_prop_validate export dav_push_error export dav_register_liveprop_group export dav_unlock export dav_validate_request export dav_validate_root export dav_xml_get_cdata export dav_xmlns_add export dav_xmlns_add_uri export dav_xmlns_create export dav_xmlns_generate export dav_xmlns_get_prefix export dav_xmlns_get_uri MOD_DAV_FS.SO export dav_fs_module MOD_DAV.SO import dav_add_response import dav_buffer_append import dav_buffer_init import dav_buffer_place import dav_buffer_place_mem import dav_check_bufsize import dav_do_find_liveprop import dav_get_liveprop_info import dav_hook_find_liveprop import dav_hook_gather_propsets import dav_hook_insert_all_liveprops import dav_lock_query import dav_new_error import dav_push_error import dav_register_liveprop_group import dav_register_provider import dav_set_bufsize import dav_xmlns_add export dav_add_all_liveprop_xmlns export dav_add_lock export dav_add_response export
Need information about Apache module development.
Dear All, We are planning for an enhancement of our servers.We are looking out if we write Apache module and use Apache to support the below requirements. We would like to use Apache as a routing layer that accepts both structured documents (XML docs) also some other predefined data blocks in addition to key/value paris via http and then routes those transactions based on a key available in the request such that the required keys and sub keys are all routed to the same rules instance - this will require the original request to be broadcast to multiple instances of the rules engine ( for example, one instance may be tracking the IP, another instance may be tracking by GUID or Screenname, and yet another may be tracking by some Signature.) A rules execution engine that is able to accept the request, evaluate a set of ops defined rules and execute various responses. There are preference of using DROOLS fusion.Any functionality in Apache based on Rules ? What are the approaches need to be taken for dynamic load balancing.Like suppose I have 3 instances of Apache is running and due to some issue one of the instance goes down.I would expect the traffic should be balanced properly by the existing 2 instances. For load balancing apart from mod_proxy_balancer any other Apache modules can be worth looking into? As and alert broadcast engine that has the ability to distribute an events to multiple end sources. As a storage layer that allows for data persistence for long term tracking of keys and values. We have the target of good performance.Is it going to be good using Apache or any other webserver would be suggestion. Inputs would be very much appreciated. Many thanks in advance -A
