Enforce rewriting of Host header when an absolue URI is given
(by default, not only with HttpProtocol strict, which is trunk only btw). Per RFC7230#section-5.4 : When a proxy receives a request with an absolute-form of request-target, the proxy MUST ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy that forwards such a request MUST generate a new Host field-value based on the received request-target rather than forward the received Host field-value. The first part is already honored, but not the forwarding part: the Host header is not rewritten with the one extracted from the absolute URI, neither at the protocol (core) level nor at proxy level. There are PR56718 (and duplicate PR57563) about this. Still the same question about whether providing the headers to some CGI or module is a forward or not, I think personally it would be sane to do this at the protocol level (beginning of the request). I proposed a patch there and refined it a bit (attached), so that section 5.4 is applied in vhost.c::fix_hostname(). It also implements this part of section 5.4 (second point, _underlined_) : A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and _to any request message that contains more than one Host header field_ or a Host header field with an invalid field-value. The first point is already handled, and the third is HttpProtocol strict dependent (which is enough I think, but maybe deserve a backport too). Thoughts? Regards, Yann. httpd-trunk-fix_hostname.patch Description: application/download
EventOpt and MotorZ
In r1664077 I made 2 changes to trunk. First of all, since all the coolness of EventOpt has been pulled into Event, there's no need to keep EventOpt around, so it's been trashed. Also... I went ahead and added MotorZ which is a mashup of Prefork and Simple, in hopes that more eyes will allow for better dev. Currently, MotorZ runs and even passes most of the Perl test framework checks (having some weird kqueue() errors on the ones where it bails). It also needs to get better SUSPEND compatibility, ala Event. As in keeping w/ Paul's original idea, MotorZ is designed to leverage APR as much as possible, and to abstract out as much core as possible to callbacks and timers, leaving a really simple logic flow. It is currently a Work In Progress.
Re: Event and RINGs
On Mar 4, 2015, at 2:43 PM, Graham Leggett minf...@sharp.fm wrote: On 04 Mar 2015, at 8:59 PM, Jim Jagielski j...@jagunet.com wrote: I am wondering if we are continuing to use RINGs in places where we should really migrate to using skiplists. afaict, we used RINGs initially because it was the only valid and available data structure we could use, but it was not idea. Even now, we aren't really using it as a FIFO queue and whenever we access it, we appear to be trying to do so in a sorted way (as related to time stamps)... I may end up doing some tests to see what the performance diffs would be if we instead just used skiplists. In my digging into how to get the request output filters to support asynchronous behaviour, what I needed was a list of filters that had setaside data, and that in turn needed to be kicked with empty brigades to keep writing until they were empty. I take it a skiplist would be a better idea for this than an APR_RING? Another place where it has become apparent that a list is required is the chain of input and output filters. Right now, they’re just linked together with next pointers, and a really ugly hack to insert or remove the first filter into the conn_rec or request_rec. Ideally these should be a linked list like an APR_RING (or a skiplist?), so they can be cleanly referenced and modified without messing about. I was thinking mostly about the way the Event MPM uses RINGs, but yeah, I can see places where skiplists could take over other areas. Since filters have a sort order, they seem like candidates for skiplists.
Event and RINGs
I am wondering if we are continuing to use RINGs in places where we should really migrate to using skiplists. afaict, we used RINGs initially because it was the only valid and available data structure we could use, but it was not idea. Even now, we aren't really using it as a FIFO queue and whenever we access it, we appear to be trying to do so in a sorted way (as related to time stamps)... I may end up doing some tests to see what the performance diffs would be if we instead just used skiplists. Besides, I think all that RING macro junk is ugly :) :) Thoughts? Comments?
Re: Event and RINGs
On 04 Mar 2015, at 8:59 PM, Jim Jagielski j...@jagunet.com wrote: I am wondering if we are continuing to use RINGs in places where we should really migrate to using skiplists. afaict, we used RINGs initially because it was the only valid and available data structure we could use, but it was not idea. Even now, we aren't really using it as a FIFO queue and whenever we access it, we appear to be trying to do so in a sorted way (as related to time stamps)... I may end up doing some tests to see what the performance diffs would be if we instead just used skiplists. In my digging into how to get the request output filters to support asynchronous behaviour, what I needed was a list of filters that had setaside data, and that in turn needed to be kicked with empty brigades to keep writing until they were empty. I take it a skiplist would be a better idea for this than an APR_RING? Another place where it has become apparent that a list is required is the chain of input and output filters. Right now, they’re just linked together with next pointers, and a really ugly hack to insert or remove the first filter into the conn_rec or request_rec. Ideally these should be a linked list like an APR_RING (or a skiplist?), so they can be cleanly referenced and modified without messing about. Regards, Graham —
Run external RewriteMap program as non-root
Hi,
currently, the External Rewriting Program (RewriteMap prg:) is run as
root. I would like to change it but I see three ways how to do it:
1. Execute it right after drop_privileges hook. This looks like best
way, but I haven't found any hook which could be used for that (except
drop_privileges with APR_HOOK_REALLY_LAST, which does not seem as proper
place to me).
2. Execute it in child_init. This is done after drop_privileges, so the
user/group is good. The problem here is that it would execute one
rewrite program per child. Right now I'm not sure if it's really
problem. It could be useful to have more instances of rewriting program
to make its bottleneck lower.
3. Execute it where it is now (post_config), but set user/group using
apr_procattr_t. So far I think this would duplicate the code of
mod_unixd and would probably have to also handle the windows equivalent
of that module (if there's any).
What way do you think is the best, or would you do it differently?
I'm attaching patch for number 2.
Regards,
Jan Kaluza
Index: modules/mappers/mod_rewrite.c
===
--- modules/mappers/mod_rewrite.c (revision 1663642)
+++ modules/mappers/mod_rewrite.c (working copy)
@@ -4449,17 +4449,6 @@
apr_pool_cleanup_register(p, (void *)s, rewritelock_remove,
apr_pool_cleanup_null);
-/* if we are not doing the initial config, step through the servers and
- * open the RewriteMap prg:xxx programs,
- */
-if (ap_state_query(AP_SQ_MAIN_STATE) == AP_SQ_MS_CREATE_CONFIG) {
-for (; s; s = s-next) {
-if (run_rewritemap_programs(s, p) != APR_SUCCESS) {
-return HTTP_INTERNAL_SERVER_ERROR;
-}
-}
-}
-
rewrite_ssl_lookup = APR_RETRIEVE_OPTIONAL_FN(ssl_var_lookup);
rewrite_is_https = APR_RETRIEVE_OPTIONAL_FN(ssl_is_https);
@@ -4485,6 +4474,11 @@
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, s, APLOGNO(00667)
mod_rewrite: could not init map cache in child);
}
+
+/* step through the servers and open the RewriteMap prg:xxx programs */
+for (; s; s = s-next) {
+run_rewritemap_programs(s, p);
+}
}
