*Match, RewriteRule POLA violation?
This came up at ApacheCon a couple of weeks ago. I just took this knowledge for granted, as I have always accounted for it, but both Rich and Trawick were surprised. As I thought about it some more, it seems this may be a POLA violation. Thoughts? If we agree it should be fixed, I can make the bugz and make a patch. Consider: Location /slash/foo ... /Location vs. LocationMatch ^/slash/foo ... /LocationMatch These do not behave the same if multiple slashes are used. The leading slashes are always coalesced, so ^/... is fine; however, any intermediate slashes are not. So, in order for the LocationMatch directive above to behave the same as the Location, it has to be specified as ^/slash/+foo. Like I said, I have always accounted for this in my regexps, but it doesn't seem right. Should the URL be normalized before being passed to regex-matching directives, or is there a specific reason that is not done? +---+--+--+--+ | Path | Non-Regex |*Match, |*Match, | | | Directive: | RewriteRule: | RewriteRule: | | | /slash/foo | ^/slash/foo | ^/slash/+foo | +---+--+--+--+ | /slash/foo| Match| Match| Match| +---+--+--+--+ | slash/foo | Match| Match| Match| +---+--+--+--+ | /slash///foo | Match| XXX | Match| +---+--+--+--+ | slash///foo// | Match| XXX | Match| +---+--+--+--+
mod_proxy, flushing additional response data
Hello, I've a patch proposal in this ticket : https://bz.apache.org/bugzilla/show_bug.cgi?id=57832 The goal is to make mod_proxy conformant to this part of rfc 7320 about the good way of preventing effects of backends compromised by http splitting/http smuggling attacks. rfc 7320: If the final response to the last request on a connection has been completely received and there remains additional data to read, a user agent MAY discard the remaining data or attempt to determine if that data belongs as part of the prior response body, which might be the case if the prior message's Content-Length value is incorrect. A client MUST NOT process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache poisoning. Currently when mod_proxy receive a response from a backend consisting of more than one response, the extra-responses are stored and reused later when another request use the same backend connection. Which is quite annoying. If you take Nginx, for example, the behavior is to send the extra responses directly to the request doing the first query, which is also wrong but less annoying because usually the first query is the one transmitting the splitting attack. Others agents are able to discard the content (Varnish, haproxy, etc.). More details in the tickets. I'm open to discussions about the right way to fix that behavior, but I think the current patch is almost good. -- Régis Leroy [regilero]
Re: Balancer manager
Can you list 'em here? I'd like to help w/ adding them :) On Apr 25, 2015, at 12:28 PM, Daniel Ruggeri drugg...@primary.net wrote: +1 There are also some neat-o features I added in my notes during ACNA to stick into the balancer manager, too... I plan to get around to them in vague, noncommittal reference to free time as it permits days. -- Daniel Ruggeri On 4/24/2015 7:52 AM, Jim Jagielski wrote: Right now, the balancer manager allows for a member to be disabled/stopped, but it cannot *remove* that member... Seems to me that that would be good, especially since we could always re-use that slot. Comments?
Re: ALPN patch comments
Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@velox.ch: On 22.04.2015 18:54, Jim Jagielski wrote: For me the time seems right to rip NPN out of trunk and only backport the ALPN code to 2.4. I'd be +1 for that. So, to get one step further, and since there were no explicit objections to removing NPN support so far (or arguments for keeping it, FWIW), I went ahead and took a stab at this with r1676004. Only tested in terms of compiles both w/ and w/o HAVE_TLS_ALPN, so it certainly needs more eyes before a backport proposal could be made. There's also a TODO: we should have a mod_ssl configuration parameter in ssl_engine_kernel.c which I'm unsure to what it refers. The „TODO“ is a leftover from before SSLAlpnPreference was introduced. It can be removed. I diff’ed the current mod_ssl against the 2.4 branch, removed everything but he ALPN changes and made a patch for my sandbox. This works on my OS X with mod_h2. My Ubuntu sandbox is still resisting as some test clients still link the system ssl which only speaks NPN (or link against a lib_event that links against the system openssl). It’s a mess. Stefan Kaspar green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
