On 23 Sep 2014, at 9:45 PM, Jim Jagielski wrote:
> APR:
> Considering that before we know it, http/2.0 will
> be here, and ignoring httpd for the time being,
> what features/additions do we see as being needed
> to support http/2.0 from an APR library level? How do
> we compare w/ libuv, for exam
Am 24.09.2014 um 23:15 schrieb Rainer Jung:
Am 24.09.2014 um 22:21 schrieb Rainer Jung:
Am 24.09.2014 um 22:15 schrieb Rainer Jung:
Am 24.09.2014 um 20:20 schrieb Eric Covener:
On Wed, Sep 24, 2014 at 1:48 PM, Paul Querna mailto:p...@querna.org>> wrote:
Thoughts? Is it reasonable to do
Am 24.09.2014 um 23:29 schrieb Yann Ylavic:
On Wed, Sep 24, 2014 at 11:15 PM, Rainer Jung wrote:
A workaround like
--- server/util_script.c.orig 2013-09-14 14:12:54.0 +
+++ server/util_script.c2014-09-24 20:35:54.952054361 +
@@ -128,6 +128,12 @@
}
On Wed, Sep 24, 2014 at 11:15 PM, Rainer Jung wrote:
> A workaround like
>
> --- server/util_script.c.orig 2013-09-14 14:12:54.0 +
> +++ server/util_script.c2014-09-24 20:35:54.952054361 +
> @@ -128,6 +128,12 @@
> }
> ++whack;
> }
> +
Am 24.09.2014 um 22:21 schrieb Rainer Jung:
Am 24.09.2014 um 22:15 schrieb Rainer Jung:
Am 24.09.2014 um 20:20 schrieb Eric Covener:
On Wed, Sep 24, 2014 at 1:48 PM, Paul Querna mailto:p...@querna.org>> wrote:
Thoughts? Is it reasonable to do something in mod_cgi{d} to improve
the si
On Wed, Sep 24, 2014 at 11:10 PM, Yann Ylavic wrote:
> On Tue, Sep 23, 2014 at 9:45 PM, Jim Jagielski wrote:
>> HTTPD:
>> From the httpd point of view, what does serf
>> provide for us to help us get to http/2.0?
>
> How about a new mod_proxy_http2 which can go async like in
> mod_proxy_wstunnel
On Tue, Sep 23, 2014 at 9:45 PM, Jim Jagielski wrote:
> HTTPD:
> From the httpd point of view, what does serf
> provide for us to help us get to http/2.0?
How about a new mod_proxy_http2 which can go async like in
mod_proxy_wstunnel (trunk)?
Some code could then be moved to input/output filters.
Am 24.09.2014 um 22:15 schrieb Rainer Jung:
Am 24.09.2014 um 20:20 schrieb Eric Covener:
On Wed, Sep 24, 2014 at 1:48 PM, Paul Querna mailto:p...@querna.org>> wrote:
Thoughts? Is it reasonable to do something in mod_cgi{d} to improve
the situation?
I don't think so, even if we trie
Am 24.09.2014 um 20:20 schrieb Eric Covener:
On Wed, Sep 24, 2014 at 1:48 PM, Paul Querna mailto:p...@querna.org>> wrote:
Thoughts? Is it reasonable to do something in mod_cgi{d} to improve
the situation?
I don't think so, even if we tried to figure out the interpreter, it
could run
On Wed, Sep 24, 2014 at 1:48 PM, Paul Querna wrote:
> Thoughts? Is it reasonable to do something in mod_cgi{d} to improve
> the situation?
>
I don't think so, even if we tried to figure out the interpreter, it could
run _anything_ else that is interpreted by bash.
But an announcement might be
http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html
https://news.ycombinator.com/item?id=8361574
I've seen a few mentions of CGI being vulnerable to attacks from this
issue. An example from the HN threads:
GET / HTTP/1.0
User-Agent: ()
It seems like recent httpd announcements are only going to
annou...@apache.org, but I could not find any discussion about it.
--
Eric Covener
cove...@gmail.com
On Tue, Sep 23, 2014 at 11:43 PM, William A. Rowe Jr.
wrote:
> I'm confused. Piped logging did work just fine on Windows, unless
> something has broken it.
>
Yes, it normally works fine, but creates two piped loggers for each access
log . One piped logger child of the parent, one piped logger
13 matches
Mail list logo
