modify request_rec->args

[Justin Kennedy]

Hello,

I have a simple module, with just a quick_hander, it's sole function is to
check if there is a specific key=value on the query string, and modify the
value, so it gets picked up by a separate module.

For example: if "foo=1" is in r->args, then replace it with "foo=0",
decline the request so it gets picked up by the other module.

In my first attempt, I created a new string and assigned the pointer to
r->args, but it doesn't seem to "stick" when it gets to the second module.
Do I have to modify r->args directly, without changing the pointer? It's
been awhile since I've worked with C strings.

Thank you,

-Justin

Re: svn commit: r1725307 - /httpd/httpd/trunk/modules/proxy/mod_proxy_hcheck.c

[Christophe JAILLET]

Le 18/01/2016 17:54, j...@apache.org a écrit :

Author: jim
Date: Mon Jan 18 16:54:12 2016
New Revision: 1725307

URL: http://svn.apache.org/viewvc?rev=1725307=rev
Log:
simplify and start on concept framework of OPTIONS

Modified:
 httpd/httpd/trunk/modules/proxy/mod_proxy_hcheck.c

Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_hcheck.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_hcheck.c?rev=1725307=1725306=1725307=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy_hcheck.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_hcheck.c Mon Jan 18 16:54:12 2016

[...]

@@ -324,13 +325,24 @@ static const char *set_hc_template(cmd_p
  
  return NULL;

  }
-static void backend_cleanup(const char *proxy_function, proxy_conn_rec 
*backend,
-server_rec *s)
+static apr_status_t backend_cleanup(const char *proxy_function, proxy_conn_rec 
*backend,
+server_rec *s, int status)
  {
  if (backend) {
  backend->close = 1;
  ap_proxy_release_connection(proxy_function, backend, s);
  }
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO()
+ "Health check %s Status (%d) for %s.",
+ ap_proxy_show_hcmethod(backend->worker->s->method),
This add a smatch warning because previous code (i.e. "if (backend)") 
assumes that 'backend' can be NULL here.



+ status,
+ backend->worker->s->name);
+if (status != OK) {
+return APR_EGENERAL;
+}
+return APR_SUCCESS;
+


[...]

Re: [PATCH] Add "FreeListen" to support IP_FREEBIND

[Yann Ylavic]

On Fri, Mar 18, 2016 at 9:36 AM, Jan Kaluža  wrote:
>
> I've implemented the way described in that question above ^. Please see the
> attached patch and share your opinions.
>
> The syntax to enable IP_FREEBIND currently is:
>
> Listen 192.168.0.1:80 http freebind

I think we should be able to configure options w/o specifying an
(arbitrary) protocol.
So "options=option1,option2=val2,..." looks a better alternative to me.

Otherwise the patch looks goods, looking forward to it (applied) so
that I can also add tcp_fastopen ;)

Thanks,
Yann.

Re: 2.4.20 Change dsp: Win32-specific build files.

[Jacob Champion]

On 03/24/2016 06:05 AM, William A Rowe Jr wrote:
> I observed the note below in 2010 when that comment was first made (I
> cribbed that comment from 2.2.x checkin).  So I now wonder if that note
> was based on an Express edition perhaps?  Or on an early release - and
> MS later added or fixed the conversion?  I can't be more specific at
> this point, but maybe someone else remembers such an issue.

I do remember from a couple of years ago that the results of the
conversion were mostly useless/broken for me, but I no longer have a
copy of VS2010 to check... so I can't offer anything more than "there
was probably a good reason to make that comment at some point". :/

--Jacob

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[William A Rowe Jr]

On Thu, Mar 24, 2016 at 11:40 AM, Jan Ehrhardt  wrote:

> William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 09:16:17
> -0500):
> >>
> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html
> >
> >It's been a *long* time, and I know it hadn't been that well maintained
> >for non-Linux (non-BSD) target architectures.
>
> On the contrary: Windows support for PHP has made a big jump. The release
> master of PHP7 is even a Microsoft employee.
>

Excellent!

>> Even in the 32-bits PHP 7 there are some:
> >>
> >>
> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html
> >
> >With a bit of luck - many of these are resolved by simply jumping up to
> >Visual Studio 2015 (and removing any number of win32-specific bandaids
> >that covered some warts in the earlier stdc lib)?
>
> Read carefully: these are the results when compiling with VC14 == VS2015.
> This is the way the official PHP7 binaries are built.
>

And in fairness, not every "conversion from 'size_t' to 'unsigned int'"
error is
actually a lurking bug.  If you know the memory allocation can't exceed some
fixed size (e.g. passed as an httpd header value that already enjoys
truncation
or rejection much earlier in the process), then that flag would generally
mean
nothing.

It's a long process to get such things 100% correct, we have a few defects
lingering in httpd 2.4 release branch today - some due to binary ABI
restrictions.
My entire point is that VC14 makes such a thing possible, where it really
wasn't possible while Microsoft was ignoring POSIX in many places.

Re: mod_status Total Accesses with 2.4.20

[Stefan Eissing]

Fix in 2.4.x: r1736465

  *) mod_http2: fix for missing score board updates on request count, fix for
 memory leak on slave connection reuse.
 
Happy Easter,

  Stefan

> Am 24.03.2016 um 17:17 schrieb Stefan Eissing :
> 
> Yes, that is how it worked and should soon work again.
> 
>> Am 24.03.2016 um 16:57 schrieb William A Rowe Jr :
>> 
>> The inner http2 response to the outer h1 upgrade request remains a 
>> single request IMHO.  Within that h2 collection of streams, each of
>> the subsequent h2 requests should then be counted individually.
>> 
>> On Thu, Mar 24, 2016 at 10:54 AM, Yann Ylavic  wrote:
>> Should the scoreboard really account for both h2 and inner h1
>> connections in the same counter?
>> It seems to me that they should be distinguish-ed/able.
>> 
>> On Thu, Mar 24, 2016 at 3:56 PM, Stefan Eissing
>>  wrote:
>>> Found it. Slave connections cleared their scoreboard handle too early (and 
>>> unneccessary) so that the update simply did not happen.
>>> 
>>> Fix will be in trunk/2.4.x soonish..
>>> 
 Am 24.03.2016 um 14:05 schrieb Stefan Eissing 
 :
 
 Quick test: http/2 connections are not counted here. checking...
 
> Am 24.03.2016 um 14:02 schrieb Steffen :
> 
> Using  server-status?auto.
> 
> Now since running with 2.4.20-dev my statistics graphs shows  less  Total 
> Accesses.
> 
> Is it not counting http/1.1 or http/2 in Total Accesses ?
> 
> Steffen
> 
 
>>> 
>> 
> 

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[Jan Ehrhardt]

William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 09:16:17
-0500):
>> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html
>
>It's been a *long* time, and I know it hadn't been that well maintained
>for non-Linux (non-BSD) target architectures.

On the contrary: Windows support for PHP has made a big jump. The release
master of PHP7 is even a Microsoft employee.

>> Even in the 32-bits PHP 7 there are some:
>>
>> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html
>
>With a bit of luck - many of these are resolved by simply jumping up to
>Visual Studio 2015 (and removing any number of win32-specific bandaids
>that covered some warts in the earlier stdc lib)?

Read carefully: these are the results when compiling with VC14 == VS2015.
This is the way the official PHP7 binaries are built.

Jan

Re: mod_status Total Accesses with 2.4.20

[Stefan Eissing]

Yes, that is how it worked and should soon work again.

> Am 24.03.2016 um 16:57 schrieb William A Rowe Jr :
> 
> The inner http2 response to the outer h1 upgrade request remains a 
> single request IMHO.  Within that h2 collection of streams, each of
> the subsequent h2 requests should then be counted individually.
> 
> On Thu, Mar 24, 2016 at 10:54 AM, Yann Ylavic  wrote:
> Should the scoreboard really account for both h2 and inner h1
> connections in the same counter?
> It seems to me that they should be distinguish-ed/able.
> 
> On Thu, Mar 24, 2016 at 3:56 PM, Stefan Eissing
>  wrote:
> > Found it. Slave connections cleared their scoreboard handle too early (and 
> > unneccessary) so that the update simply did not happen.
> >
> > Fix will be in trunk/2.4.x soonish..
> >
> >> Am 24.03.2016 um 14:05 schrieb Stefan Eissing 
> >> :
> >>
> >> Quick test: http/2 connections are not counted here. checking...
> >>
> >>> Am 24.03.2016 um 14:02 schrieb Steffen :
> >>>
> >>> Using  server-status?auto.
> >>>
> >>> Now since running with 2.4.20-dev my statistics graphs shows  less  Total 
> >>> Accesses.
> >>>
> >>> Is it not counting http/1.1 or http/2 in Total Accesses ?
> >>>
> >>> Steffen
> >>>
> >>
> >
> 

Re: mod_status Total Accesses with 2.4.20

[Yann Ylavic]

Should the scoreboard really account for both h2 and inner h1
connections in the same counter?
It seems to me that they should be distinguish-ed/able.

On Thu, Mar 24, 2016 at 3:56 PM, Stefan Eissing
 wrote:
> Found it. Slave connections cleared their scoreboard handle too early (and 
> unneccessary) so that the update simply did not happen.
>
> Fix will be in trunk/2.4.x soonish..
>
>> Am 24.03.2016 um 14:05 schrieb Stefan Eissing :
>>
>> Quick test: http/2 connections are not counted here. checking...
>>
>>> Am 24.03.2016 um 14:02 schrieb Steffen :
>>>
>>> Using  server-status?auto.
>>>
>>> Now since running with 2.4.20-dev my statistics graphs shows  less  Total 
>>> Accesses.
>>>
>>> Is it not counting http/1.1 or http/2 in Total Accesses ?
>>>
>>> Steffen
>>>
>>
>

Re: mod_status Total Accesses with 2.4.20

[William A Rowe Jr]

The inner http2 response to the outer h1 upgrade request remains a
single request IMHO.  Within that h2 collection of streams, each of
the subsequent h2 requests should then be counted individually.

On Thu, Mar 24, 2016 at 10:54 AM, Yann Ylavic  wrote:

> Should the scoreboard really account for both h2 and inner h1
> connections in the same counter?
> It seems to me that they should be distinguish-ed/able.
>
> On Thu, Mar 24, 2016 at 3:56 PM, Stefan Eissing
>  wrote:
> > Found it. Slave connections cleared their scoreboard handle too early
> (and unneccessary) so that the update simply did not happen.
> >
> > Fix will be in trunk/2.4.x soonish..
> >
> >> Am 24.03.2016 um 14:05 schrieb Stefan Eissing <
> stefan.eiss...@greenbytes.de>:
> >>
> >> Quick test: http/2 connections are not counted here. checking...
> >>
> >>> Am 24.03.2016 um 14:02 schrieb Steffen :
> >>>
> >>> Using  server-status?auto.
> >>>
> >>> Now since running with 2.4.20-dev my statistics graphs shows  less
> Total Accesses.
> >>>
> >>> Is it not counting http/1.1 or http/2 in Total Accesses ?
> >>>
> >>> Steffen
> >>>
> >>
> >
>

Re: mod_status Total Accesses with 2.4.20

[Steffen]

Like to see it in 2.4.20, because my reporting is broken.

-Original Message- 
From: Stefan Eissing

Sent: Thursday, March 24, 2016 3:56 PM
To: dev@httpd.apache.org
Subject: ** Re: mod_status Total Accesses with 2.4.20

Found it. Slave connections cleared their scoreboard handle too early (and 
unneccessary) so that the update simply did not happen.


Fix will be in trunk/2.4.x soonish..

Am 24.03.2016 um 14:05 schrieb Stefan Eissing 
:


Quick test: http/2 connections are not counted here. checking...


Am 24.03.2016 um 14:02 schrieb Steffen :

Using  server-status?auto.

Now since running with 2.4.20-dev my statistics graphs shows  less  Total 
Accesses.


Is it not counting http/1.1 or http/2 in Total Accesses ?

Steffen

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[Yann Ylavic]

On Thu, Mar 24, 2016 at 3:40 PM, William A Rowe Jr  wrote:
> On Thu, Mar 24, 2016 at 9:31 AM, Yann Ylavic  wrote:
>>
>> Not to talk about they very personal conception of sizeof(long) on
>> 64bit systems...
>
> You might be too young to remember when pointers had little to
> no relation to integer registers on many cpu architectures :)

I'm afraid not :(
I wasn't talking about pointers here, though, but I agree that numeric
types have never been something consistent accross platforms either.

Simply now that char/short/int/long types could have had (finally!)
there own size, and a common and consistent agreement on, for all/most
modern systems... it failed.

They surely had good reasons to do so, though it might just have
moved/postponed the issues (to portable coders, at least). But after
all, let's all use the APR! :)

Re: mod_status Total Accesses with 2.4.20

[Stefan Eissing]

Found it. Slave connections cleared their scoreboard handle too early (and 
unneccessary) so that the update simply did not happen.

Fix will be in trunk/2.4.x soonish..

> Am 24.03.2016 um 14:05 schrieb Stefan Eissing :
> 
> Quick test: http/2 connections are not counted here. checking...
> 
>> Am 24.03.2016 um 14:02 schrieb Steffen :
>> 
>> Using  server-status?auto.
>> 
>> Now since running with 2.4.20-dev my statistics graphs shows  less  Total 
>> Accesses.
>> 
>> Is it not counting http/1.1 or http/2 in Total Accesses ?
>> 
>> Steffen
>> 
> 

Re: [VOTE] access control for dynamic hosts

[fabien]

Hello Yann,


I guess this question is for me, not the doc :)


Yep!

[...] So, finally, mentioning that *any* ip/host-based authz should be 
combined with other authz/authn (SSL certificates, credentials schemes, 
...) for stronger requirements may be the way to go.


I agree that combining authz is the way to go, esp. with sensitive 
applications which are more and more hosted outside of organizations, or 
even provided as SaaS.


I'm not sure of a good place to discuss authorization policies in general 
in the documentation though.



Or maybe simply not change the doc since all this might be quite obvious...


I would be fine with this solution:-)

--
Fabien.

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[William A Rowe Jr]

On Thu, Mar 24, 2016 at 9:31 AM, Yann Ylavic  wrote:

> >> nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or
> >> variable may be unsafe. Consider using vsnprintf_s instead. To disable
> >> deprecation, use _CRT_SECURE_NO_WARNINGS.
>
> [sarcasm]
> Microsoft being unable to provide a safe vsnprintf() in the first
> place and now warning every user is kind of ironic.
>

Microsoft claims that all the non-MS foo_s variants that have buffer
targets as defined by POSIX are insecure, and offer foo_s variants.
We have apr's safe strncpy etc, so it's not like we didn't agree -
at least for some cases.

They are free to make any claim they like, but they offered an out...
from these warnings ... -D_CRT_SECURE_NO_DEPRECATE


> Not to talk about they very personal conception of sizeof(long) on
> 64bit systems...
>

You might be too young to remember when pointers had little to
no relation to integer registers on many cpu architectures :)

[/sarcasm]
>
> Not a very constructive comment, I agree :)
>

:)

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[Yann Ylavic]

>> nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or
>> variable may be unsafe. Consider using vsnprintf_s instead. To disable
>> deprecation, use _CRT_SECURE_NO_WARNINGS.

[sarcasm]
Microsoft being unable to provide a safe vsnprintf() in the first
place and now warning every user is kind of ironic.

Not to talk about they very personal conception of sizeof(long) on
64bit systems...
[/sarcasm]

Not a very constructive comment, I agree :)

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[William A Rowe Jr]

On Thu, Mar 24, 2016 at 8:49 AM, Jan Ehrhardt  wrote:

> William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 07:58:45
> -0500):
> >Precisely, Jan.  We don't know where these truncation errors lead - do
> they
> >portentially open security holes?  They cetainly interefere with serving
> >huge resources such as .iso images.
> >
> >When I first tripped over this, I breifly pondered putting together a
> >patch.  PHP, httpd (through apr) dealt with all this long ago.
>
> Apparently, you never compiled PHP 5.5/5.6/7.0 on Windows 64-bits. There
> are loads of 'possible loss of data' warnings. See for yourself:
>
> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html


It's been a *long* time, and I know it hadn't been that well maintained
for non-Linux (non-BSD) target architectures.


> Even in the 32-bits PHP 7 there are some:
>
> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html


With a bit of luck - many of these are resolved by simply jumping up to
Visual Studio 2015 (and removing any number of win32-specific bandaids
that covered some warts in the earlier stdc lib)?

Remaining errors likely still need fixing.  That sizeof(int) == sizeof(void
*)
assumption from 64ILP architectures is *not* part of the spec.  We have
64ILP (int == long == void*), 64LP (long == void* != int) as well as
64P (long == int != void*) and each of these are valid architectures.

The various types such as ptrdiff_t that POSIX exposes *should* resolve
these all when the correct types are chosen, and that is now true with
MSVC 14 on Windows as well.  It just becomes a matter of using the
true and correct type for various operations.

Cheers,

Bill

Re: mod_http2 on Windows (was: Re: Status for 2.4.20)

[Jan Ehrhardt]

William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 07:58:45
-0500):
>Precisely, Jan.  We don't know where these truncation errors lead - do they
>portentially open security holes?  They cetainly interefere with serving
>huge resources such as .iso images.
>
>When I first tripped over this, I breifly pondered putting together a
>patch.  PHP, httpd (through apr) dealt with all this long ago.

Apparently, you never compiled PHP 5.5/5.6/7.0 on Windows 64-bits. There
are loads of 'possible loss of data' warnings. See for yourself:
http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html

Even in the 32-bits PHP 7 there are some:
http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html

Jan

Re: [VOTE] access control for dynamic hosts

[Yann Ylavic]

Hi Fabien,

On Wed, Mar 23, 2016 at 6:12 PM,   wrote:
>
> How about adding something like:
>
> From a security perspective, getting access to a protected page is somehow
> easier with "forward-dns" because the attacker needs only to control the DNS
> for the domain, while they would also need to control the reverse DNS with
> "host". Now, if you have important confidential data, they would not be
> only protected by host-based authorizations, would they?

I guess this question is for me, not the doc :)
Right, host-based is not the state of the art of authorizations, that
could also be documented for both "forward-dns" and "host"... maybe
without asking for an agreement from the reader? ;)

But reverse DNS is actually also easier to control than forward
anyway, so in both cases it really boils down to controlling the
configured host's domain (or the DNS/resolver used by the server).

So, finally, mentioning that *any* ip/host-based authz should be
combined with other authz/authn (SSL certificates, credentials
schemes, ...) for stronger requirements may be the way to go.
Or maybe simply not change the doc since all this might be quite obvious...

Regards,
Yann.

Re: apr_global_mutex_create vs apr_proc_mutex_create

[William A Rowe Jr]

proc_mutex can only be used to block on a cross process event.  It can be
used in a threaded server, but cannot be held in multiple threads, you
might use it to block in a single thread queue per-process.

Thread_mutex will not block between processes, this is used for the
mutex-per-process logic such as a across accept wait queues.

Global_mutex will block, across threads and across processes, as
appropriate.
On Mar 24, 2016 04:08, "Luca Toscano"  wrote:

> +httpd-dev@
>
> Hello!
>
> 2016-03-23 21:49 GMT+01:00 Ali Shah :
>
>> Hi Module maintainers,
>>
>> I'm writing a simple apache module and I'd like to aggregate some
>> statistics.
>> I saw an example module that does this (
>> https://wiki.apache.org/httpd/ModuleLife) using shared memory.
>>
>> My question for those on this list following:
>>
>> What is the main difference between using mutexes created
>> via apr_global_mutex_create and apr_proc_mutex_create in terms of
>> performance and safety of the resource that being protected?
>>
>> The docs seem to discourage usage of apr_global_mutex_create:
>> "There is considerable overhead in using this API if only cross-process or
>> cross-thread mutual exclusion is required."
>>
>> Is the overhead purely in code setup (since global mutex should be
>> initialized in post_config), or is this describing some performance
>> penalties as well?
>>
>
> From what I can see in [1] a global lock uses both apr_proc_mutex_create
> and apr_thread_mutex_create, so this is why the documentation suggests the
> use of a more specialized one if only cross-process or cross-thread sync is
> needed.
>
> Not a great explanation I know, somebody else with more experience will
> give you a better answer on this list :)
>
> Luca
>
>
>
> [1]:
> https://github.com/apache/apr/blob/7951861fb029fd0fb60e5ec8da73015d03afa28d/locks/unix/global_mutex.c#L46
>
>
>

Re: apr_global_mutex_create vs apr_proc_mutex_create

[William A Rowe Jr]

proc_mutex can only be used to block on a cross process event.  It can be
used in a threaded server, but cannot be held in multiple threads, you
might use it to block in a single thread queue per-process.

Thread_mutex will not block between processes, this is used for the
mutex-per-process logic such as a across accept wait queues.

Global_mutex will block, across threads and across processes, as
appropriate.
On Mar 24, 2016 04:08, "Luca Toscano"  wrote:

> +httpd-dev@
>
> Hello!
>
> 2016-03-23 21:49 GMT+01:00 Ali Shah :
>
>> Hi Module maintainers,
>>
>> I'm writing a simple apache module and I'd like to aggregate some
>> statistics.
>> I saw an example module that does this (
>> https://wiki.apache.org/httpd/ModuleLife) using shared memory.
>>
>> My question for those on this list following:
>>
>> What is the main difference between using mutexes created
>> via apr_global_mutex_create and apr_proc_mutex_create in terms of
>> performance and safety of the resource that being protected?
>>
>> The docs seem to discourage usage of apr_global_mutex_create:
>> "There is considerable overhead in using this API if only cross-process or
>> cross-thread mutual exclusion is required."
>>
>> Is the overhead purely in code setup (since global mutex should be
>> initialized in post_config), or is this describing some performance
>> penalties as well?
>>
>
> From what I can see in [1] a global lock uses both apr_proc_mutex_create
> and apr_thread_mutex_create, so this is why the documentation suggests the
> use of a more specialized one if only cross-process or cross-thread sync is
> needed.
>
> Not a great explanation I know, somebody else with more experience will
> give you a better answer on this list :)
>
> Luca
>
>
>
> [1]:
> https://github.com/apache/apr/blob/7951861fb029fd0fb60e5ec8da73015d03afa28d/locks/unix/global_mutex.c#L46
>
>
>

Re: mod_status Total Accesses with 2.4.20

[Stefan Eissing]

Quick test: http/2 connections are not counted here. checking...

> Am 24.03.2016 um 14:02 schrieb Steffen :
> 
> Using  server-status?auto.
> 
> Now since running with 2.4.20-dev my statistics graphs shows  less  Total 
> Accesses.
> 
> Is it not counting http/1.1 or http/2 in Total Accesses ?
> 
> Steffen
> 

Re: 2.4.20 Change dsp: Win32-specific build files.

[William A Rowe Jr]

Steffan,

I was plesantly surprised when I tested this on an early VS2015 preview and
the conversion was still supported.

I observed the note below in 2010 when that comment was first made (I
cribbed that comment from 2.2.x checkin).  So I now wonder if that note was
based on an Express edition perhaps?  Or on an early release - and MS later
added or fixed the conversion?  I can't be more specific at this point, but
maybe someone else remembers such an issue.
On Mar 24, 2016 05:39, "Steffen"  wrote:

> Good now.
>
> Little note:  Visual Studio 2010 users cannot convert our .dsp files.
> That's not true, I convert them.
>
> Steffen
>
>
>
> From: William A Rowe Jr Sent: Wednesday, March 23, 2016 9:23 PM
> To: httpd Subject: * Re: 2.4.20 Change dsp: Win32-specific build
> files.
>
> On Wed, Mar 23, 2016 at 11:12 AM, Steffen  wrote:
>
> I went earlier back, so I did a .dsp/GUI build with no issues.
> Build with SVN revision 1736328.
>
> Running looks also fine sofar.
>
>
>
>
>
> Glad to hear, thanks for testing.  I've updated the commit log message
> to more clearly explain the intent and avoid future confusion;
>
> +Going forwards, keep win32 build in svn once a tree is stable.
> +Visual Studio 2010 users cannot convert our .dsp files, and
> +ddk toolchain users couldn't either.
> +
> +Applies the same logic as r1100294 on the 2.2.x branch.
> +
> Until the cmake build schema is entirely mature, these files
> are needed for command-line builds of the 2.4 tree, and are
> expected to change very little until the EOL of 2.4 branch.
> -The actual .dsp files are entirely unusable for any shipping
> -version of MSVC/Visual Studio, while the .mak exports of these
> -projects are usable on any flavor of the MS build environment.
> +
> +The .dsp source files are not directly usable for any shipping
> +version of MSVC/Visual Studio (post-Visual Studio 97 release),
> +while the .mak exports of these projects are usable on any flavor
> +of the MS nmake build environment.  The .dsp source files are
> +retained for those users wishing to import these projects into
> +the modern vcproj/sln file format.
>
>
> Hope that is more clear, further edit suggestions are welcome.
>
>
> Cheers,
>
>
> Bill
>

mod_status Total Accesses with 2.4.20

[Steffen]

Using  server-status?auto.

Now since running with 2.4.20-dev my statistics graphs shows  less  Total 
Accesses.

Is it not counting http/1.1 or http/2 in Total Accesses ?

Steffen

mod_http2 on Windows (was: Re: Status for 2.4.20)

[William A Rowe Jr]

On Mar 23, 2016 22:19, "Jan Ehrhardt"  wrote:
>
> William A Rowe Jr in gmane.comp.apache.devel (Wed, 23 Mar 2016 08:00:19
> -0500):
> >On Wed, Mar 23, 2016 at 7:42 AM, William A Rowe Jr 
> >wrote:
> >
> >> Again, a C89 regression breaking the candidate, but in an experimental
> >> module that we don't promise will always build.  nghttp2 is filled
with C99
> >> code, AIUI - due to bad decisions about basic C types - that library
can
> >> only build.
> >>
> >Whoops, answering too quickly...
> >
> >that library can only build *correctly* under the latest MSVC 14 (aka
> >Studio 2015) when you are compiling for 64-bits on Windows (not an issue
> >with 32 bit builds).
>
> How do you define 'correctly'? nghttp2 (git head) builds with only a
> single warning on VC14 x86:
>
> c:\php-sdk\prebuilt\nghttp2\lib\nghttp2_session.c(6767) : warning C4715:
> 'nghttp2_session_get_remote_settings': not all control paths return a
> value
>
> VC11 x86 and VC9 x86 builds of nghttp2 give a couple of extra warnings:
>
> nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or
> variable may be unsafe. Consider using vsnprintf_s instead. To disable
> deprecation, use _CRT_SECURE_NO_WARNINGS.
>
> All x64 builds issue many more warnings:
>
> cl -nologo -MD  -W3 -Z7 -DBUILDING_NGHTTP2 -I./includes -Dssize_t=long
> -D_U_="" -FoMSVC_obj /r_nghttp2_session.obj -c nghttp2_session.c
> nghttp2_session.c
> nghttp2_session.c(5092): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(5122): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(5477): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(5704): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(5888): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(5952): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(6082): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data
> nghttp2_session.c(6191): warning C4244: 'return': conversion from
> '__int64' to 'long', possible loss of data

Precisely, Jan.  We don't know where these truncation errors lead - do they
portentially open security holes?  They cetainly interefere with serving
huge resources such as .iso images.

When I first tripped over this, I breifly pondered putting together a
patch.  PHP, httpd (through apr) dealt with all this long ago.

But nghttp2 is a modern C99/POSIX app, why ask the author to code around
Win32-isms, now that MS finally got these right with the VC14 release?

Re: svn commit: r1736217 - in /httpd/httpd/trunk/include: ap_hooks.h ap_mmn.h

[Ruediger Pluem]

On 03/24/2016 12:59 PM, Jeff Trawick wrote:
> On Thu, Mar 24, 2016 at 5:56 AM, Ruediger Pluem  > wrote:
> 
> 
> 
> On 03/22/2016 06:38 PM, yla...@apache.org  
> wrote:
> > Author: ylavic
> > Date: Tue Mar 22 17:38:20 2016
> > New Revision: 1736217
> >
> > URL: http://svn.apache.org/viewvc?rev=1736217=rev
> > Log:
> > core: Add missing AP_IMPLEMENT_OPTIONAL_HOOK_RUN_FIRST.
> >
> > Modified:
> > httpd/httpd/trunk/include/ap_hooks.h
> > httpd/httpd/trunk/include/ap_mmn.h
> >
> > Modified: httpd/httpd/trunk/include/ap_hooks.h
> 
> > Modified: httpd/httpd/trunk/include/ap_mmn.h
> > URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1736217=1736216=1736217=diff
> > 
> ==
> > --- httpd/httpd/trunk/include/ap_mmn.h (original)
> > +++ httpd/httpd/trunk/include/ap_mmn.h Tue Mar 22 17:38:20 2016
> > @@ -518,6 +518,7 @@
> >   * ap_mpm_register_poll_callback_timeout and
> >   * ap_mpm_unregister_poll_callback. Add
> >   * AP_MPMQ_CAN_POLL.
> > + * 20160315.1 (2.5.0-dev)  Add AP_IMPLEMENT_OPTIONAL_HOOK_RUN_FIRST.
> >   */
> >
> >  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
> >
> >
> >
> 
> You forgot the real bump :-)
> 
> 
> Remembering to do the real bump is the exception :)
> 

There is a test in the test suite covering this. This is how I found this btw. 
:-)

Regards

Rüdiger

Re: svn commit: r1736217 - in /httpd/httpd/trunk/include: ap_hooks.h ap_mmn.h

[Jeff Trawick]

On Thu, Mar 24, 2016 at 5:56 AM, Ruediger Pluem  wrote:

>
>
> On 03/22/2016 06:38 PM, yla...@apache.org wrote:
> > Author: ylavic
> > Date: Tue Mar 22 17:38:20 2016
> > New Revision: 1736217
> >
> > URL: http://svn.apache.org/viewvc?rev=1736217=rev
> > Log:
> > core: Add missing AP_IMPLEMENT_OPTIONAL_HOOK_RUN_FIRST.
> >
> > Modified:
> > httpd/httpd/trunk/include/ap_hooks.h
> > httpd/httpd/trunk/include/ap_mmn.h
> >
> > Modified: httpd/httpd/trunk/include/ap_hooks.h
>
> > Modified: httpd/httpd/trunk/include/ap_mmn.h
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1736217=1736216=1736217=diff
> >
> ==
> > --- httpd/httpd/trunk/include/ap_mmn.h (original)
> > +++ httpd/httpd/trunk/include/ap_mmn.h Tue Mar 22 17:38:20 2016
> > @@ -518,6 +518,7 @@
> >   * ap_mpm_register_poll_callback_timeout and
> >   * ap_mpm_unregister_poll_callback. Add
> >   * AP_MPMQ_CAN_POLL.
> > + * 20160315.1 (2.5.0-dev)  Add AP_IMPLEMENT_OPTIONAL_HOOK_RUN_FIRST.
> >   */
> >
> >  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
> >
> >
> >
>
> You forgot the real bump :-)
>

Remembering to do the real bump is the exception :)

Maybe we need a commit hook???


>
> Regards
>
> Rüdiger
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1736217 - in /httpd/httpd/trunk/include: ap_hooks.h ap_mmn.h

[Yann Ylavic]

On Thu, Mar 24, 2016 at 10:56 AM, Ruediger Pluem  wrote:
>
> You forgot the real bump :-)

Thanks :) fixed in r1736428.

Re: Status for 2.4.20

[Jim Jagielski]

Tell you what. Let's delay for 1 week and I'll take up a T
on Monday April 4th.

Re: 2.4.20 Change dsp: Win32-specific build files.

[Steffen]

Good now.

Little note:  Visual Studio 2010 users cannot convert our .dsp files.
That's not true, I convert them.

Steffen



From: William A Rowe Jr 
Sent: Wednesday, March 23, 2016 9:23 PM
To: httpd 
Subject: * Re: 2.4.20 Change dsp: Win32-specific build files.


On Wed, Mar 23, 2016 at 11:12 AM, Steffen  wrote:

I went earlier back, so I did a .dsp/GUI build with no issues. 


Build with SVN revision 1736328.

Running looks also fine sofar.





Glad to hear, thanks for testing.  I've updated the commit log message
to more clearly explain the intent and avoid future confusion;

+Going forwards, keep win32 build in svn once a tree is stable.
+Visual Studio 2010 users cannot convert our .dsp files, and
+ddk toolchain users couldn't either.
+
+Applies the same logic as r1100294 on the 2.2.x branch.
+
Until the cmake build schema is entirely mature, these files
are needed for command-line builds of the 2.4 tree, and are
expected to change very little until the EOL of 2.4 branch.
-The actual .dsp files are entirely unusable for any shipping
-version of MSVC/Visual Studio, while the .mak exports of these
-projects are usable on any flavor of the MS build environment.
+
+The .dsp source files are not directly usable for any shipping
+version of MSVC/Visual Studio (post-Visual Studio 97 release),
+while the .mak exports of these projects are usable on any flavor
+of the MS nmake build environment.  The .dsp source files are
+retained for those users wishing to import these projects into
+the modern vcproj/sln file format.


Hope that is more clear, further edit suggestions are welcome.


Cheers,


Bill

Re: svn commit: r1736217 - in /httpd/httpd/trunk/include: ap_hooks.h ap_mmn.h

[Ruediger Pluem]

On 03/22/2016 06:38 PM, yla...@apache.org wrote:
> Author: ylavic
> Date: Tue Mar 22 17:38:20 2016
> New Revision: 1736217
> 
> URL: http://svn.apache.org/viewvc?rev=1736217=rev
> Log:
> core: Add missing AP_IMPLEMENT_OPTIONAL_HOOK_RUN_FIRST.
> 
> Modified:
> httpd/httpd/trunk/include/ap_hooks.h
> httpd/httpd/trunk/include/ap_mmn.h
> 
> Modified: httpd/httpd/trunk/include/ap_hooks.h

> Modified: httpd/httpd/trunk/include/ap_mmn.h
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1736217=1736216=1736217=diff
> ==
> --- httpd/httpd/trunk/include/ap_mmn.h (original)
> +++ httpd/httpd/trunk/include/ap_mmn.h Tue Mar 22 17:38:20 2016
> @@ -518,6 +518,7 @@
>   * ap_mpm_register_poll_callback_timeout and
>   * ap_mpm_unregister_poll_callback. Add
>   * AP_MPMQ_CAN_POLL.
> + * 20160315.1 (2.5.0-dev)  Add AP_IMPLEMENT_OPTIONAL_HOOK_RUN_FIRST.
>   */
>  
>  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
> 
> 
> 

You forgot the real bump :-)

Regards

Rüdiger

Re: Questions on writing logging stmts in httpd

[Luca Toscano]

Hi!

Don't have a lot of context but I found some answers in the httpd code (see
inline comments):

2016-03-24 2:07 GMT+01:00 Tianyin Xu :

> I find a previous post,
> http://marc.info/?t=14057931881=1=2
>
> which helped answer the 2nd question, basically, "anything more important
> than DEBUG needs a number."
>
> but it does not answer the Question #1 and #3 :-|
>
> ~t
>
>
>
> On Wed, Mar 23, 2016 at 5:55 PM, Tianyin Xu  wrote:
>
>> Hi folks,
>>
>> I've a question regarding writing logging statements in httpd code. I
>> notice that most of the logging statements are associated with a log
>> number, defined by the APLOGNO macro, while some others (in the same
>> module) do not. I have the following questions when writing new logging
>> statements,
>>
>> 1. What are these log numbers used for? (I remember the early versions do
>> not have these...)
>>
>
More info in
https://github.com/apache/httpd/blob/trunk/include/http_log.h#L111


>
>> 2. What kinds of logs need the log numbers and what do not?
>>
>> 3. How to determine the number when writing a new logging statement? Is
>> there any specific rule to generate the number? If not, how to avoid the
>> collision?
>>
>
More info in
https://github.com/apache/httpd/tree/trunk/docs/log-message-tags

Hope that helps!

Luca

Re: apr_global_mutex_create vs apr_proc_mutex_create

[Luca Toscano]

+httpd-dev@

Hello!

2016-03-23 21:49 GMT+01:00 Ali Shah :

> Hi Module maintainers,
>
> I'm writing a simple apache module and I'd like to aggregate some
> statistics.
> I saw an example module that does this (
> https://wiki.apache.org/httpd/ModuleLife) using shared memory.
>
> My question for those on this list following:
>
> What is the main difference between using mutexes created
> via apr_global_mutex_create and apr_proc_mutex_create in terms of
> performance and safety of the resource that being protected?
>
> The docs seem to discourage usage of apr_global_mutex_create:
> "There is considerable overhead in using this API if only cross-process or
> cross-thread mutual exclusion is required."
>
> Is the overhead purely in code setup (since global mutex should be
> initialized in post_config), or is this describing some performance
> penalties as well?
>

>From what I can see in [1] a global lock uses both apr_proc_mutex_create
and apr_thread_mutex_create, so this is why the documentation suggests the
use of a more specialized one if only cross-process or cross-thread sync is
needed.

Not a great explanation I know, somebody else with more experience will
give you a better answer on this list :)

Luca



[1]:
https://github.com/apache/apr/blob/7951861fb029fd0fb60e5ec8da73015d03afa28d/locks/unix/global_mutex.c#L46