Re: http/2, spdy and bears, oh my!
On 05 Feb 2014, at 9:09 PM, Jim Jagielski j...@jagunet.com wrote: With http/2 becoming closer and closer, and spdy being in place as we speak, it seems that we should really ramp up development on trunk to support these new techs. Lets get serious on what needs to be done w/ trunk to get there, and what our wish-list is for new capability and architecture. Taking a page from mod_spdy, breaking the connection-request singularity looks like an interesting 1st step, maybe via some sort of virtual connection which a real connection can spin up/down and which corresponds to the request's actual connection... My moon-on-a-stick wishlist is as follows. I want more from the MPMs. Most specifically, what I want is: - The ability to create and associate additional connections with the original incoming connection, creating a set of associated connections, all controlled by the same event loop. If mod_proxy wants to make a connection, I want to be able to tie it into the same event loop that is driving the frontend. It should not matter where the connections come from, they could be local pipes, doesn't matter. - The ability to mask events. Messing around with lists of sockets is a colossal faff, ideally the MPM should worry about this and the module developer shouldn't care. What I want is the ability, at any time, to mask an event on a connection in a simple and easy to understand way. While I am waiting for a ready-to-read from a backend proxy, I want to mask the ready-to-write to the frontend, and I don't want this to be fiddly. - First class support for openssl. The SSL protocol is a layer, meaning that while we may be trying to read, openssl underneath might be trying to either read or write to perform a renegotiation. What openssl asks us to do is switch to a write in the middle of a read, or a read in the middle of a write. We must support this properly from the get go with the ability to override the sense of any event from a write to a read or a read to a write. In the past the MPMs have ignored openssl expecting to handle it as some kind of special case, and this is wrong. Regards, Graham --
Re: Revisiting: xml2enc, mod_proxy_html and content compression
Thanks for the patch! On 02/05/2014 02:57 PM, Nick Kew wrote: The hesitation is because I've been wanting to review the patch before committing, and round tuits are in woefully short supply. So I'm attaching it here. I'll take any feedback from you or other users as a substitute for my own review, and commit if it works for you without glitches. Minor glitch: the patch doesn't compile because it uses the unknown variable cfg in xml2enc_ffunc(). Otherwise it works as advertised. My wishlist: * Make the configuration option as powerful as the compiled in fallback so that you can configure eg. contains xml. But how would you do that? Support regular expressions? * Provide a configuration option to blacklist content types so that you can use the defaults that are compiled in but exclude specific types from processing (this is how I work around the Sharepoint problem, I simply exclude content type multipart/related).
Adding AddHandler support for mod_proxy
Hi,
I have an improvement request to suggest but I would like to first provide
some background to justify it, I apologise for the long email :).
I'm actively using mod_proxy to forward PHP files requests to PHP-FPM. My
current approach is to use a RewriteRule with the 'P' flag because (in most
of the cases) it plays nicely with other rules configured by the
applications I'm configuring, as well as allowing per-Directory
configurations.
To make it properly work I must assure the proxy RewriteRule must be the
latest one to be evaluated. The problem is that from time to time I
encounter corner cases in which the rules previously executed include a [L]
option that abort the next rules evaluation, skipping the proxy one, making
Apache serve the PHP text as plain text. This can be solved by tweaking the
rules but it is a tedious process and is hard to determine all the
scenarios in which the rewrites could go wrong.
Thinking about my goal with all of this was at the beginning, I realised I
only wanted a way of configuring a handler for all my PHP files, that in
this case is PHP-FPM, without having to worry about what happens before the
resource is going to be served. This made my think about the possibility of
adding this functionality to mod_proxy itself, allowing defining a proxy
worker as a handler for certain types of files. Something like:
AddHandler proxy:unix:/path/to/app.sock|fcgi://localhost/ .php
I made a quick POC, it is a really small change and for those in my
situation it could really simplify the configuration of their apps. Of
course, I'm open to criticisms and alternative solutions :).
The code that adds the new functionality is inserted at the beginning of
mod_proxy's proxy_handler. The conditions are a little weird because I only
wanted to check the handler if it is not a proxy request already.
diff --git a/modules/proxy/mod_proxy.c b/modules/proxy/mod_proxy.c
index 9d7c92f..49f3bdc 100644
--- a/modules/proxy/mod_proxy.c
+++ b/modules/proxy/mod_proxy.c
@@ -927,8 +927,20 @@ static int proxy_handler(request_rec *r)
struct dirconn_entry *list = (struct dirconn_entry
*)conf-dirconn-elts;
/* is this for us? */
-if (!r-proxyreq || !r-filename || strncmp(r-filename, proxy:, 6)
!= 0)
+if (!r-filename)
+ return DECLINED;
+
+if (!r-proxyreq) {
+ if (r-handler strncmp(r-handler, proxy:, 6) == 0
strncmp(r-filename, proxy:, 6) != 0) {
+r-proxyreq = PROXYREQ_REVERSE;
+r-filename = apr_pstrcat(r-pool, r-handler, r-filename, NULL);
+apr_table_setn(r-notes, rewrite-proxy, 1);
+ } else {
return DECLINED;
+ }
+} else if (strncmp(r-filename, proxy:, 6) != 0) {
+ return DECLINED;
+}
/* handle max-forwards / OPTIONS / TRACE */
if ((str = apr_table_get(r-headers_in, Max-Forwards))) {
Best regards,
Juanjo.
[PATCH 55467] - Updates to mod_ssl to support TLS hello extensions and TLS supplemental data
Support for sending and receiving TLS hello extensions and TLS supplemental data messages has recently been added to the OpenSSL GitHub master branch. I’ve submitted a patch to mod_ssl which allows third-party modules to send and receive TLS hello extensions and TLS supplemental data via optional hooks and functions. The patch can be found here: https://issues.apache.org/bugzilla/show_bug.cgi?id=55467 I’m happy to update the patch based on feedback. Thanks much, Scott Deboy
agent-based framework for httpd private keys [was: Re: SSL_CTX_get_{first,next}_certificate]
On 02/06/2014 12:35 AM, Kaspar Brand wrote: On 05.02.2014 18:13, Falco Schwarz wrote: Kaspar, I ran into another issue when using an encrypted private key and SSLOpenSSLConfCmd PrivateKey. Again it fails to load the encrypted private key with the following errors: That's by design, see [1]. Eventually I'd like to drop support for encrypted private keys from trunk. As part of the goal of dropping encrypted private key support, have you considered using an agent-based framework for private keys? As a point of reference, OpenSSH added agent-based host key support for sshd on 2013-07-20. tTe basic model is: 0) there is a running agent that holds secret key material and listens on a socket (unix-domain sockets are nice because of the possibility of tight filesystem permission control) 1) the daemon (httpd, sshd) knows how to talk to the agent, to request a list of available keys, and to request signing or decryption operations to be done by the keys. 2) the agent has a set of rules that govern when and how to obey a specific request for signing or decryption operations 3) the sysadmin has an interface to load password-protected keys into the agent. You can also run the agent under a different user account than the web server, so that a runaway web server process wouldn't have access to the secret key material without some other privilege escalation. And you can commit to a very small-footprint agent, with less room for bugs and exploits, as compared to the entire modular webserver. PKCS#11 is one formalization of this approach (though i think that PKCS #11's shared object interface itself is pretty problematic in today's multi-core/multi-threaded/multi-process architectures). Anyway, with some sort of agent-based approach, you could preserve encrypted keys-on-disk (for Joe Orton's examples of admins with access to full-machine backups, or secret-keys-on-NFS) while leaving apache agnostic about the way the keys get *into* the agent. --dkg signature.asc Description: OpenPGP digital signature
