Re: [Bug 57785] REDIRECT_URL is not suitable for use in server-generated pages

On Fri, 23 Oct 2015 15:22:27 -0400 Eric Covener wrote: > My opinion is to make it opt-in before the next 2.4, but I am not > committed to that. Hehe. I was leaning towards introducing separate vars for full URL and fragment. But your patch looks good to me. -- Nick Kew

Re: [Bug 57785] REDIRECT_URL is not suitable for use in server-generated pages

+1 on this as well. That looks like a good fix that won’t break existing functionality. I know a lot of apps are working on updates now to fix these changes, but it’ll still be good to have this pushed back a bit. Thank you! — Jacob Perkins Product Owner cPanel Inc. jacob.perk...@cpanel.net

Re: [Bug 57785] REDIRECT_URL is not suitable for use in server-generated pages

On Fri, Oct 23, 2015 at 9:22 PM, Eric Covener wrote: > My opinion is to make it opt-in before the next 2.4, but I am not > committed to that. > > Before I do doc, any other thoughts? > > http://people.apache.org/~covener/patches/redirecturl-optin.diff Looks sensible, +1

Fwd: [Bug 57785] REDIRECT_URL is not suitable for use in server-generated pages

My opinion is to make it opt-in before the next 2.4, but I am not committed to that. Before I do doc, any other thoughts? http://people.apache.org/~covener/patches/redirecturl-optin.diff This adds a directive to core.c called QualifyRedirectURL that must be set to ON to run the 2.4.17 code. --

Re: [users@httpd] Chunked transfer delay with httpd 2.4 on Windows.

On 10/22/2015 04:50 PM, Yann Ylavic wrote: On Thu, Oct 22, 2015 at 3:42 PM, Andy Wang wrote: Tested with the patch and looks good. Not that much actually, the patch fails to consume the CRLFs, and hence can end up in an infinite loop. So I'm attaching a new one here (committed in trunk wi

Re: master connection + mod_ssl + http2

> On Oct 21, 2015, at 10:25 AM, Graham Leggett wrote: > > On 21 Oct 2015, at 2:42 PM, Stefan Eissing > wrote: > >> The basic changes: >> 1. conn_rec->master is NULL for HTTP/1.1 connections, but points to the >> "real" connection for HTTP/2 requests. >> 2. mod_ssl no longer initalizes any SS

Re: mod_proxy's aside connections proposal

On Tue, Mar 3, 2015 at 9:20 AM, Jim Jagielski wrote: > I guess the main question is what are the actual use-cases? NTLM at the very least. That's the context it comes up in periodically.

Re: segfault analysis

On Fri, Oct 23, 2015 at 12:23 PM, Stefan Eissing wrote: > > Hmm, I think the best way to tackle this is to transfer the worker into a > zombie set from worker_done(). Then in h2_workers_register(), which is called > regularly and often, join the threads and destroy the zombie workers. That's fi

Re: segfault analysis

Code review is a fine thing... Hmm, I think the best way to tackle this is to transfer the worker into a zombie set from worker_done(). Then in h2_workers_register(), which is called regularly and often, join the threads and destroy the zombie workers. Allocating the worker from parent_pool is

Re: segfault analysis

On Fri, Oct 23, 2015 at 12:13 PM, Yann Ylavic wrote: > > since the worker destroys itself in its own thread (pool == w->pool). > > Also, where are the worker threads joined? Actually I find both joining the worker thread and then worker_destroy() should be done in h2_workers_destroy(), after work

Re: segfault analysis

On Fri, Oct 23, 2015 at 10:42 AM, Stefan Eissing wrote: > > In regard to https://bz.apache.org/bugzilla/show_bug.cgi?id=58524 We possibly need this too: Index: modules/http2/h2_worker.c === --- modules/http2/h2_worker.c(revision

Re: segfault analysis

Yes, you are correct. The mutex holds. I had my head in java synchronized waits for a second *shudder*... > Am 23.10.2015 um 12:05 schrieb Yann Ylavic : > > On Fri, Oct 23, 2015 at 11:59 AM, Stefan Eissing > wrote: >> >> The problem with the unlock in release is that the h2_mplx might have bee

Re: segfault analysis

On Fri, Oct 23, 2015 at 11:59 AM, Stefan Eissing wrote: > > The problem with the unlock in release is that the h2_mplx might have been > destroyed by then, as the signal might give the lock to someone waiting. Hm, h2_mplx_release_and_join() (which destroys the mplx) won't be woken up until the m

Re: segfault analysis

Nice analysis, btw. I think you found the problem. I'll replace the timed wait by a simple wait... > Am 23.10.2015 um 11:22 schrieb Yann Ylavic : > > On Fri, Oct 23, 2015 at 11:18 AM, Yann Ylavic wrote: >> >> Index: modules/http2/h2_mplx.c >> ===

Re: segfault analysis

;-) The problem with the unlock in release is that the h2_mplx might have been destroyed by then, as the signal might give the lock to someone waiting. I could move that mutex into h2_session ownership, just lending it to h2_mplx... //Stefan > Am 23.10.2015 um 11:22 schrieb Yann Ylavic : > >

Re: segfault analysis

On Fri, Oct 23, 2015 at 11:18 AM, Yann Ylavic wrote: > > Index: modules/http2/h2_mplx.c > === > --- modules/http2/h2_mplx.c(revision 1710105) > +++ modules/http2/h2_mplx.c(working copy) > @@ -143,12 +143,18 @@ static void refe

Re: segfault analysis

On Fri, Oct 23, 2015 at 10:42 AM, Stefan Eissing wrote: > > Can I recover any files/lines from these > === Backtrace: = > /lib64/libc.so.6[0x32a507174f] > /lib64/libc.so.6(cfree+0x4b)[0x32a5075a4b] > /opt/appl/apr-1.5.2/lib/libapr-1.so.0(apr_allocator_destroy+0x1b)[0x2abbed566e6b] > /o

segfault analysis

A question to the more experienced httpd debuggers: In regard to https://bz.apache.org/bugzilla/show_bug.cgi?id=58524 Can I recover any files/lines from these === Backtrace: = /lib64/libc.so.6[0x32a507174f] /lib64/libc.so.6(cfree+0x4b)[0x32a5075a4b] /opt/appl/apr-1.5.2/lib/libapr-1.so