Re: mod_proxy_http2 windows build

[Jan Ehrhardt]

Stefan Eissing in gmane.comp.apache.devel (Wed, 18 May 2016 17:09:46
+0200):
>Reaching out to the knowledgable and always helpful Windows people: do we
>need a mod_proxy_http2.dsp in trunk/modules/http2 (and 2.4.x branch for
>next release)?

The project files for the 2.4.x branch I am using at the moment are here:
https://github.com/Jan-E/mod_h2/commit/b370975acbf1366e0c56d967a909795bdc3e74a2

However, I cannot tell for sure mod_proxy_http.so works, because I do not
use it. mod_http2.so v1.5.5 is running fine since yesterday (VC9, x86 and
VC11, x64)

Jan

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

Re-sending to include the correct perl.a.o dev list.

On Thu, Apr 14, 2016 at 1:25 PM, William A Rowe Jr 
wrote:

> The defect appears to be in t/protocol/TestProtocol/pseudo_http.pm...
>
> First, the handler is registered using
>
>   PerlProcessConnectionHandler TestProtocol::pseudo_http
>
> so its activities are outside of the request handling phase.
>
> Note that this logic has been broken, for a long time;
>
>2.4.1>
>   
>   Order Deny,Allow
>   Allow from @servername@
>   
>   
>
> Where @servername@ is a hostname, this module defect was
> identified in version 2.4.20 when we began using the per-req
> hostname in comparison (based on r->useragent_addr, which
> is obviously is null during part of the read_request phase).
>
> But this module using mod_access_compat during the connection
> phase has been broken for much longer, since Allow from {ip-addr}
> would already have failed since 2.4.1 was released, due to the
> same null r->useragent_addr.
>
> Effectively, mod_access_compat.c never supported per-connection
> IP addresses since it was added.  The fact that it supported
> per-connection hostname comparison was a quirk, and that the
> pseudo_http tests only looked at hostname and not ip comparisons
> was an oversight.
>
> But the module will fail in other manners if attempting to use
> http request_rec processing since that record is never fleshed
> out with the proper read/post_read request hook phases.
>
> My thought is to simply decouple access_compat from this
> module test... opinions?
>
> See also; https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824;msg=5
>
>
> On Thu, Apr 14, 2016 at 11:55 AM, William A Rowe Jr 
> wrote:
>
>> We can be more vigilant about unexpectedly null values, however...
>>
>> how are you running request processing in the connection callback
>> of mod_perl?  That makes no sense, and probably signals a deeper
>> logic error.
>>
>> The access checker is configured per-dir, so until the request rec
>> is completely initialized during read_request, this doesn't make
>> much sense to me (full backtrace .. including frames #6-#10, for
>> those who are curious...)
>>
>> Either the callback list registered for modperl_callback_connection,
>> or the Perl_runops_standard, or the Perl_pp_entersub invoking the
>> run_access_checker hook seem the most suspect here.
>>
>> #0  apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, sockaddr=0x0, 
>> flags=flags@entry=0)
>> at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663
>> #1  0x55feaf0f513a in ap_get_useragent_host (r=r@entry=0x7fd4461ee0a0, 
>> type=type@entry=3,
>> str_is_ip=str_is_ip@entry=0x7fd44740c9c4) at core.c:990
>> #2  0x7fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, 
>> method=method@entry=0, a=,
>> a=) at mod_access_compat.c:279
>> #3  0x7fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at 
>> mod_access_compat.c:332
>> #4  0x55feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) 
>> at request.c:87
>> #5  0x7fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker 
>> (my_perl=0x55feb2964a20, cv=)
>> at HookRun.c:235
>> #6  0x7fd44f5f7e6a in Perl_pp_entersub () from 
>> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #7  0x7fd44f5f0ca6 in Perl_runops_standard () from 
>> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #8  0x7fd44f575f06 in Perl_call_sv () from 
>> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #9  0x7fd44f91ec28 in modperl_callback 
>> (my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750,
>> p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, 
>> args=0x55feb3beebd0)
>> at modperl_callback.c:100
>> #10 0x7fd44f91f576 in modperl_callback_run_handlers (idx=0, 
>> type=type@entry=1, r=r@entry=0x0,
>> c=, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, 
>> ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
>> at modperl_callback.c:236
>> #11 0x7fd44f91fd4f in modperl_callback_connection (idx=, 
>> c=,
>> run_mode=) at modperl_callback.c:359
>> #12 0x55feaf10cdf0 in ap_run_process_connection 
>> (c=c@entry=0x7fd4461f22b8) at connection.c:42
>> #13 0x55feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, 
>> csd=csd@entry=0x7fd4461f20a0)
>> at connection.c:226
>> #14 0x7fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, 
>> my_thread_num=1, my_child_num=0,
>> sock=0x7fd4461f20a0, p=0x7fd4461f2028, thd=0x7fd453eb27a0) at 
>> worker.c:631
>> #15 worker_thread (thd=0x7fd453eb27a0, dummy=) at worker.c:990
>> #16 0x7fd453418454 in start_thread (arg=0x7fd44740d700) at 
>> pthread_create.c:334
>> #17 0x7fd453155ecd in clone () at 
>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>>
>>
>> Before we chase down a potential non-defect in httpd, any thoughts
>> on the underlying modperl or script logic?
>>
>>
>> On Thu, Apr 14, 2016 at 

Re: Task #85e57cec: Improve the Request Processing guide

[Luca Toscano]

+docs@

Hi!

2016-05-18 20:49 GMT+02:00 Onder SEZGIN :

> Hi,
>
> I would like to contribute to the task.
> Any guidance how i can do that is appreciated.
>

I would start from https://httpd.apache.org/docs-project/, that contains
all the basic info to make a change to the httpd documentation. Then the
task requires a full immersion in httpd's request processing code to write
down a good overview in
https://httpd.apache.org/docs/2.4/developer/request.html. We also have
HTTP/2 support now so the task is more challenging and interesting (Stefan
has already written down some good docs in https://icing.github.io/mod_h2/).

Please note a couple of things:
- This task will require knowledge of C and httpd's internals, plus a lot
of time :)
- This email list should be kept as free as possible from random questions
about httpd's internals, so a good idea would be to batch doubts that you
might have and ask some guidance once in a while. At least, this is how I
try to balance my desire to know vs spamming the httpd's devels.
- The task is part of a major effort to expand
https://httpd.apache.org/docs/2.4/developer. The idea would be to ease the
initial ramp up for people interested in understanding httpd's internals
(and possibly submitting changes). This docs section already contains super
good docs like https://httpd.apache.org/docs/2.4/developer/modguide.html,
but it needs a bit of care and love.
- There are good IRC communication channels on freenode, namely #httpd and
#httpd-dev.

Thanks a lot for your interest!

Luca

mod_fcgid: Immediate HTTP error 503 if the max total process count is reached

[Ivan Zahariev]

  
  
Hi all,

I'd like to propose a new configuration setting for "mod_fcgid". The
source code changes to review follow:

  The whole patch compared to version 2.3.9:
https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait?diff=split=maxnowait
  The whole patch as a single file:
https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait.patch?diff=unified=maxnowait
  Every single commit compared to version 2.3.9:
https://github.com/famzah/mod_fcgid/commits/maxnowait
  There should be no merge conflicts with the current "trunk"
version 2.3.10.


The motivation is that the current behavior to queue up new pending
requests differs from the RLimitNPROC directive behavior. When there
is a spike in the web hits, lots of Apache children get busy just
waiting for up to 30+ seconds to get an idle FastCGI process. Thus
we "waste" Apache children doing nothing while they could serve
static content. This also puts unneeded memory pressure.
Additionally, users today won't wait for a page to load, if it takes
more than a few seconds, and we'd rather notify them that we are
currently overloaded by sending them a 503 HTTP response
immediately.

Here is the documentation for the new directive:
http://www.famzah.net/temp/FcgidMaxProcessesUsedNoWait.docs.txt

Let me know what you think.

Best regards.
--Ivan
  

Re: mod_proxy_http2 windows build

[William A Rowe Jr]

On May 18, 2016 6:08 PM, "Jan Ehrhardt"  wrote:
>
> William A Rowe Jr in gmane.comp.apache.devel (Wed, 18 May 2016 14:54:41
> -0500):
> >The .dsp files become irrelevant in this day and age, the legacy
environment
> >it maps to is entirely dead and beyond availability (snip)...
>
> Yet they are still the preferred way of building Apache by the people at
> Apachelounge. And the .mak files are preferred by Gregg at Apachehaus.

Although I've tweaked them for the past 10 years for separate APR vs httpd
builds, my headless build environments all had relied on .mak files.

CMake is essentially there, but I would never have figured out what httpd
was doing if I couldn't easily bring in httpd project files into Visual
Studio '98 a long time ago,, instrument it for browser source code
references, and toggle JIT debugging and step through within a few hours of
first digging into httpd 1.3.10.

I hope we keep things that simple, zero-intervention httpd builds, and
GUI/guided build environments such as visual studio, eclipse, etc