Re: [VOTE] Release httpd-2.4.57-rc1 as httpd-2.4.57

2023-04-04 Thread Marion & Christophe JAILLET




Le 03/04/2023 à 21:44, Christophe JAILLET a écrit :

Le 02/04/2023 à 18:10, Eric Covener a écrit :

Hi all,

Please find below the proposed release tarball and signatures:

https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release
this candidate tarball httpd-2.4.57-rc1 as 2.4.57:
[X] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha256: bc3e7e540b83ec24f9b847c6b4d7148c55b79b27d102e21227eb65f7183d6b45
*httpd-2.4.57-rc1.tar.gz
sha512: 
730560d4aab3699aa59716bb75858f8432a902aeab3c380b4d3e0f6813e9ae4e278d3b7fdf63a4e94c07b5100933d8684d76f6095f3d60d48ea0f1458c9ed0b4

*httpd-2.4.57-rc1.tar.gz

The SVN candidate source is found at tags/2.4.57-rc1-candidate.



+1

Tested only with event.

Tested with:
Linux pop-os 6.2.0
gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
   libssl-dev 3.0.2
   libbrotli-dev 1.0.9
   libjansson-dev 2.13.1
   libnghttp2-dev 1.43.0
   libpcre2-dev 10.39
   liblua5.3-dev 5.3.6
   libsystemd-dev 249.11
   libldap2-dev 2.5.14+dfsg
   libxml2-dev 2.9.13+dfsg
   libcurl4-openssl-dev 7.81.0


Still can't get the pytest run correctly.
I've tried to make some clean-ups. Should have a real look at it one day :(


> pip install -U multipart
did the trick. (thanks error.log!)

I don't know if it is a new requirement or if I did something wrong on 
my setup.


Does is worth mentioning in README.pytest?



Another point, when building mod_tls.
After upgrading to latest github rustls-ffi, I now get:

tls_core.c: In function ‘extract_client_hello_values’:
tls_core.c:510:14: error: ‘rustls_client_hello’ has no member named 
‘sni_name’

  510 | if (hello->sni_name.len > 0) {
  |  ^~
tls_core.c:511:55: error: ‘rustls_client_hello’ has no member named 
‘sni_name’
  511 | cc->sni_hostname = apr_pstrndup(c->pool, 
hello->sni_name.data, hello->sni_name.len);

  |   ^~
tls_core.c:511:77: error: ‘rustls_client_hello’ has no member named 
‘sni_name’
  511 | cc->sni_hostname = apr_pstrndup(c->pool, 
hello->sni_name.data, hello->sni_name.len);



Apparently related to:

https://github.com/rustls/rustls-ffi/commit/ed82a03f2481095f251e7aee604a2ca29b8c1c5e#diff-6f7bcae64b59e4d5ad181e43c27a22088434c36827db05f8767e00dabcd7973eR426


So, maybe some trouble and conditional compilation to come in a close 
future.




This module is tagged as experimental, so from my POV it can't be a show 
stopper.


CJ


Re: svn commit: r1905387 - /httpd/httpd/branches/2.4.x/STATUS

2022-11-18 Thread Marion & Christophe JAILLET

Hi Emmanuel,

just a nit: every commit triggers our CI (see [1]). This helps to spot 
new build issues and regression.


When a commit does not change the code itself, triggering the CI is not 
really useful and will likely only waste some CPU and bandwidth.
So when only STATUS, CHANGES or documentation are changed, you can add 
in the commit text the string "[skip ci]".


On the contrary, if for some reason a regression or build issue has been 
introduced, you can also touch these files (removing a trailing space, 
fixing a typo, ...) to force the CI to run.


If of interest to you, where to find CI reports is also explained in [1].


Happy hacking :)

CJ

[1]: https://httpd.apache.org/dev/devnotes.html#continuous-integration-ci



Le 19/11/2022 à 02:45, m...@apache.org a écrit :

Author: manu
Date: Sat Nov 19 01:45:24 2022
New Revision: 1905387

URL: http://svn.apache.org/viewvc?rev=1905387=rev
Log:
Backport ptoposal for DAVlockDiscovery option, and attempt to open DAVLockDB
read-only when possible.

Modified:
 httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1905387=1905386=1905387=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Sat Nov 19 01:45:24 2022
@@ -282,6 +282,20 @@ PATCHES/ISSUES THAT ARE BEING WORKED
   make it nonblocking (by default)?
  jim: Non-blocking seems the best way to handle...
  
+  *) mod_dav: Open the lock database read-only when possible

+ trunk patch: http://svn.apache.org/r1905229
+ 2.4.x patch: trunk works
+ +1: manu
+
+  *) mod_dav: DAVlockDiscovery option to disable WebDAV lock discovery
+ This is a game changer for performances if client use PROPFIND a lot,
+ trunk patch: http://svn.apache.org/r1904638
+  http://svn.apache.org/r1904662
+  http://svn.apache.org/r1905170
+  http://svn.apache.org/r1905206
+  http://svn.apache.org/r1905230
+ 2.4.x patch: trunk works
+ +1: manu
  
  PATCHES/ISSUES THAT ARE STALLED
  





Re: svn commit: r1896361 - /httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c

2022-01-07 Thread Marion & Christophe JAILLET



Le 07/01/2022 à 14:13, Ruediger Pluem a écrit :


On 12/24/21 2:49 PM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Fri Dec 24 13:49:35 2021
New Revision: 1896361

URL: http://svn.apache.org/viewvc?rev=1896361=rev
Log:
Close a file handle in case of error in ct_static_scts()

PR 65760 

Modified:
 httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c

Modified: httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c?rev=1896361=1896360=1896361=diff
==
--- httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c (original)
+++ httpd/httpd/trunk/modules/ssl/mod_ssl_ct.c Fri Dec 24 13:49:35 2021
@@ -2967,6 +2967,7 @@ static const char *ct_static_scts(cmd_pa
  
  cert = PEM_read_X509(pemfile, NULL, NULL, NULL);

  if (!cert) {
+fclose(pemfile);

Couldn't we just move that before the if and remove the previously existing 
call?

Regards

Rüdiger


Hi,


if you mean something like:

https://github.com/tititiou36/httpd/commit/1348607c00ba58ce371f2f8ecb08abf610227043

Yes, this is just fine for me.


CJ




Re: migration of the HTTPD project website

2021-06-29 Thread Marion & Christophe JAILLET

Hi Dave,

Thanks for having done it.

You did faster and better than what I had started.


Here are a few details spotted here and there:
   - The download page looks broken
 (https://httpd.staged.apache.org/download.cgi)

   - some '&' have been turned into 
 (https://httpd.staged.apache.org/dev/debugging.htmll#gcore)

   - some extra spaces in a command (around the use of awk)
(https://httpd.staged.apache.org/dev/release.html#how-to-do-a-release)

   - a bold string left with **
 (https://httpd.staged.apache.org/dev/styleguide.html)

   - a link that is left as [foo](bar) instead of an hypertext link
 (at the very bottom of https://httpd.staged.apache.org/contributors/)

Only the first point is an issue. It is maybe linked to the fact that it 
is in staging?


I guess that all the other tiny things could be fixed easily but don't 
have time to look at it by myself in the coming days/weeks.



I don't know if you hand modified a few things, but several places looks 
better now (some spacing between paragraphs which are smaller now, some 
alignment, some missing spaces between words that have been fixed, some 
numbering that were broken and fixed now, some links that have been 
added for URL or mails). So, great work!


Thanks a lot.

CJ



Le 25/06/2021 à 19:12, Dave Fisher a écrit :

The Migration from CMS to ASF-Pelican is staged!

https://httpd.staged.apache.org/ is ready.

https://github.com/apache/httpd-site/

See the README on GitHub for details.

All The Best,
Dave


On Jun 22, 2021, at 11:00 AM, Dave Fisher  wrote:




On Jun 21, 2021, at 6:26 AM, Eric Covener  wrote:

On Sun, Jun 20, 2021 at 3:25 PM Andrew Wetmore  wrote:

Hi, Eric:

Yes, committers can use either GitHub or Gitbox.

I am not sure what the "can you give a hint about the migration aspect" means. 
Maybe I was not clear. We have to move all projects off the Apache CMS and to some other 
technology, such as Pelican. Infra can help with that move to a Git repository. Sometime 
this summer the Apache CMS will stop functioning, which would mean you would have a hard 
time updating your website.

I was referring to  "...migration process available that could speed
things along." not the overall migration off the CMS.
Daniel referred to
https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features
but I didn't find any reference to "migration".

https://github.com/apache/httpd-site was created but it's empty.  I
was assuming we'd have some starting point based on the CMS-based site
content and whatever additional template/scaffolding is needed that
we'd be able to see w/o replacing our currently published site.
I don't want anyone to start from scratch if there's a better way to
get started.

I have the go ahead to do the migration for you. The goal is to create a staged 
site that will be nearly identical to your current site.

Expect more information this week.

All The Best,
Dave




Re: NOTICE: Intent to T on Sunday May 16, 2021

2021-05-16 Thread Marion & Christophe JAILLET

Hi all,

the issues that have shown up just before the announcement of 2.4.48 
seem to be gone now.


So I'll T a new 2.4.48 for testing later today.

CJ

Le 03/05/2021 à 21:29, Christophe JAILLET a écrit :

Hi all,

as you probably have noticed, the 2.4.47 has been distributed on mirrors 
but not announced, neither on your favorite ML, nor on the official 
httpd.apache.org website.


The reason is a very last minute regression discovered a few hours 
before the announcement.


So, as the 2.4.32 release in March 2018, this 2.4.47 release will never 
be officially announced.



In the hope of this issue being solved in the meantime, I plan a new T 
on Sunday May 16, 2021, forecasting for a 2.4.48 release on Sunday May 
23 or Monday May 24.



Best regards,
Christophe JAILLET



Re: svn commit: r1885610 - in /httpd/httpd/branches/2.4.x: ./ modules/dav/main/ modules/md/ modules/proxy/ modules/session/ modules/ssl/ server/

2021-01-17 Thread Marion & Christophe JAILLET



Le 17/01/2021 à 18:07, minf...@apache.org a écrit :

Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1885610=1885609=1885610=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Sun Jan 17 17:07:42 2021
@@ -1,6 +1,15 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.4.47
  
+  *) Synch 2.4.x and trunk

+   - mod_dav: save a few cycles
+   - mod_{ssl,md}: init_stapling_status hooks should return an int
+   - util_md5: avoid temporary stack result in ap_md5_binary()
+   - mod_proxy_balancer: Add a missing 
+   - mod_md: get_stapling_status hooks should return an int
+   - mod_session: Improve a message about SessionExpiryUpdateInterval 
values
+ [Christophe Jaillet]
+
   


Entry not needed, IMOH.

Their are no user visible changes.

CJ



Re: Broken: apache/httpd#1394 (2.4.x - fa22b50)

2021-01-17 Thread Marion & Christophe JAILLET


Le 17/01/2021 à 18:02, Graham Leggett a écrit :

Hi all,

https://travis-ci.com/github/apache/httpd/builds/213431494?utm_medium=notification_source=email 
 
failed for what looks like missing perl libraries:


t/modules/proxy_websockets.t  Can't locate 
AnyEvent/WebSocket/Client.pm in @INC (you may need to install the 
AnyEvent::WebSocket::Client module) (@INC contains: 
/home/travis/build/apache/httpd/test/perl-framework/blib/lib 
/home/travis/build/apache/httpd/test/perl-framework/blib/arch 
/home/travis/build/apache/httpd/test/perl-framework 
/home/travis/perl5/lib/perl5/5.26.1/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1 
/home/travis/perl5/lib/perl5/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1 
/home/travis/perl5/lib/perl5/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5 
/home/travis/perl5/lib/perl5/5.26.0/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.0 
/home/travis/perl5/lib/perl5/5.26.0/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.1 
/home/travis/perl5/lib/perl5/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5 /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.26.1 
/usr/local/share/perl/5.26.1 /usr/lib/x86_64-linux-gnu/perl5/5.26 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 
/usr/share/perl/5.26 /home/travis/perl5/lib/perl5/5.26.0 
/home/travis/perl5/lib/perl5/5.26.0/x86_64-linux-gnu-thread-multi 
/home/travis/perl5/lib/perl5/5.26.0 
/home/travis/perl5/lib/perl5/5.26.0/x86_64-linux-gnu-thread-multi 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at 
t/modules/proxy_websockets.t line 10.
2718BEGIN failed--compilation aborted at t/modules/proxy_websockets.t 
line 10.
2719t/modules/proxy_websockets.t  Dubious, test returned 2 
(wstat 512, 0x200)

2720No subtests run




Regards,
Graham
—



Should be fixed by r1885608

CJ



Re: Your project's website

2020-11-11 Thread Marion & Christophe JAILLET

Hi,

I have something that seems to work pretty well on my machine.

The main steps done so far are:

   - install pelican

   - move, as-is, the content of the old CMS into the content/pages/ 
directory of pelican


   - rename .mdtext files into .md files
 find . -name '*.mdtext' -exec sh -c 'mv "$0" "${0%.mdtext}.md"' {} \;

   - copy the 'simple' template from pelican

   - tweak the base.html and page.html from this template

   - move some css and images in the static/css and static/images 
directories of the theme template


   - move the the 'navigation.mdtext' from the template directory of 
the old CMS to the content/pages/ directory in order to keep its 
markdown syntax
    (I've not been able to use Markdown within the template, and I've 
adapted the solution proposed in 
https://stackoverflow.com/questions/60759348/how-to-include-a-markdown-file-in-index-html)


   - make some tweak here and there (the {.centered} in the main 
index.md file doesn't work the same for exemple)


Still need some testing but the result is visually the same for what 
have looked at.


To be continued.

CJ


Le 10/11/2020 à 21:21, Marion & Christophe JAILLET a écrit :


Hi,

I'll try to give a look at Pelican to see what I can get out of it.
I agree with Daniel that it shouldn't be to difficult. But it may take 
some time to install/test/tweak the site as I've never used Pelican 
before.


Moreover, we have some scripts that update the CMS when we make a 
release that will need some attention too.


CJ

Le 10/11/2020 à 15:22, Andrew Wetmore a écrit :

Hi, all:

Any progress on the site migration? Is there a Jira ticket for 
tracking this work?


Thanks in advance.

Andrew

On Tue, Aug 18, 2020 at 10:59 AM Andrew Wetmore <mailto:andr...@apache.org>> wrote:


Hi:

Any progress finding someone to handle the site migration?
Initial steps include:

- deciding what technology to move to, either Pelican, Hugo,
GitHub Pages or some other static site generator
- recording a formal PMC decision to make the move
- opening a Jira ticket for INFRA to help us track what we need
to do to facilitate the move.

Thanks!

Andrew

On Wed, Aug 5, 2020 at 9:17 AM Andrew Wetmore mailto:andr...@apache.org>> wrote:

Hi:

I am part of the Infrastructure team, and am writing to ask
whether your project is still using the Apache CMS for your
project website. As you know, the CMS is reaching
end-of-life, and we need projects to move their websites onto
a different option within the next few weeks.

There are several alternatives available, including those
listed on this page [1] on managing project websites. Infra
is assembling a Wiki page [2] on migrating a website from the
CMS, and is looking forward to helping projects with this
transition.

Please let me know whether your site is still on the Apache
CMS and, if so, who will be the project point-of-contact with
Infra for the migration.

Thank you!




[1] https://infra.apache.org/project-site.html
<https://infra.apache.org/project-site.html>

[2]

https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS

<https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS>



-- 
Andrew Wetmore

Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org <mailto:andr...@apache.org>


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free. www.avast.com

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>




-- 
Andrew Wetmore

Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org <mailto:andr...@apache.org>



--
Andrew Wetmore
Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org <mailto:andr...@apache.org>


Re: Your project's website

2020-11-10 Thread Marion &amp; Christophe JAILLET

Hi,

I'll try to give a look at Pelican to see what I can get out of it.
I agree with Daniel that it shouldn't be to difficult. But it may take 
some time to install/test/tweak the site as I've never used Pelican before.


Moreover, we have some scripts that update the CMS when we make a 
release that will need some attention too.


CJ

Le 10/11/2020 à 15:22, Andrew Wetmore a écrit :

Hi, all:

Any progress on the site migration? Is there a Jira ticket for 
tracking this work?


Thanks in advance.

Andrew

On Tue, Aug 18, 2020 at 10:59 AM Andrew Wetmore > wrote:


Hi:

Any progress finding someone to handle the site migration? Initial
steps include:

- deciding what technology to move to, either Pelican, Hugo,
GitHub Pages or some other static site generator
- recording a formal PMC decision to make the move
- opening a Jira ticket for INFRA to help us track what we need to
do to facilitate the move.

Thanks!

Andrew

On Wed, Aug 5, 2020 at 9:17 AM Andrew Wetmore mailto:andr...@apache.org>> wrote:

Hi:

I am part of the Infrastructure team, and am writing to ask
whether your project is still using the Apache CMS for your
project website. As you know, the CMS is reaching end-of-life,
and we need projects to move their websites onto a different
option within the next few weeks.

There are several alternatives available, including those
listed on this page [1] on managing project websites. Infra is
assembling a Wiki page [2] on migrating a website from the
CMS, and is looking forward to helping projects with this
transition.

Please let me know whether your site is still on the Apache
CMS and, if so, who will be the project point-of-contact with
Infra for the migration.

Thank you!




[1] https://infra.apache.org/project-site.html


[2]

https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS





-- 
Andrew Wetmore

Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org 



Virus-free. www.avast.com






-- 
Andrew Wetmore

Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org 



--
Andrew Wetmore
Technical Writer-Editor
Infra
*Apache Software Foundation*
andr...@apache.org 


Re: svn commit: r1880395 - in /httpd/httpd/trunk: CHANGES modules/http2/h2_push.c modules/http2/h2_push.h modules/http2/h2_version.h

2020-07-29 Thread Marion &amp; Christophe JAILLET



Le 29/07/2020 à 14:15, ic...@apache.org a écrit :

Author: icing
Date: Wed Jul 29 12:15:58 2020
New Revision: 1880395

URL: http://svn.apache.org/viewvc?rev=1880395=rev
Log:
   *) mod_http2: remote support for abandoned http-wg draft


remove?

CJ




Re: svn commit: r1782986 - /httpd/httpd/trunk/server/util_filter.c

2020-07-06 Thread Marion &amp; Christophe JAILLET

Thx for both of you for the explanation.

Le 06/07/2020 à 11:56, Yann Ylavic a écrit :

[...]
Finally APR_BUCKET_IS_{EOS,}(e) on an EMPTY brigade is always false
with the current struct apr_bucket_brigade API.


That's also my understanding. That is what was puzzling me.


Just a bit fragile :)


Ok. Better safe than sorry.

CJ


Regards;
Yann.


Re: svn commit: r1876937 - /httpd/httpd/trunk/modules/ssl/ssl_engine_init.c

2020-04-24 Thread Marion &amp; Christophe JAILLET



Le 24/04/2020 à 21:02, Ruediger Pluem a écrit :


On 4/24/20 7:04 PM, yla...@apache.org wrote:

Author: ylavic
Date: Fri Apr 24 17:04:28 2020
New Revision: 1876937

URL: http://svn.apache.org/viewvc?rev=1876937=rev
Log:
mod_ssl: follow up to r1876934: OSSL_PARAM_construct_*() make no copy.

Pass OSSL_PARAM_construct_octet_string() an explicit copy of the MAC key
to avoid saving a pointer to stack.

While at it, cleanup secret data from buf before leaving.

Modified:
 httpd/httpd/trunk/modules/ssl/ssl_engine_init.c

Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?rev=1876937=1876936=1876937=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_init.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_init.c Fri Apr 24 17:04:28 2020

@@ -1616,6 +1617,7 @@ static apr_status_t ssl_init_ticket_key(
  res = SSL_CTX_set_tlsext_ticket_key_evp_cb(mctx->ssl_ctx,
 ssl_callback_SessionTicket);
  #endif
+memset(buf, 0, sizeof(buf));

I cannot remember the gory details, but I remember a discussion either here or 
in APR land that these memset calls might be
optimized away by a compiler. I only found a quick reference on the Internet to 
this topic:

https://www.cryptologie.net/article/419/zeroing-memory-compiler-optimizations-and-memset_s/

Regards

Rüdiger



See apr_crypto_memzero in APR trunk at least.

CJ



Re: Travis notifications for trunk?

2020-04-23 Thread Marion &amp; Christophe JAILLET



Le 23/04/2020 à 12:20, Joe Orton a écrit :

In the past two weeks we've had three true negative build failures from
Travis on trunk - i.e. bugs were introduced and CI caught them - and one
false negative (where the gcc 9 build broke because of some change in
the Ubuntu repo).  So I think we're reaching the point where signal is
dominating noise.

Is everybody OK with sending e-mail notifications for CI failures for
trunk to this list?  It's quite likely we will still see occassional
false negatives, and can continue to mark as "allowed failure" any build
combination which looks unstable, so it doesn't fail the job overall.

As with 2.4.x we will only see fail->pass and pass->fail transitions via
e-mail notification.

Regards, Joe


+1. This is just great. Thanks.


CJ


Re: svn commit: r1875947 - in /httpd/httpd/trunk: include/http_request.h modules/http/http_core.c modules/http/http_request.c server/core.c server/core_filters.c server/request.c server/util_filter.c

2020-04-03 Thread Marion &amp; Christophe JAILLET



Le 03/04/2020 à 20:41, Ruediger Pluem a écrit :

I am undecided. I am not entirely convinced that it is a good name although all 
you said above is true, but on the other hand it
is not that bad that I see a need to spend a lot of further time on this name 
searching topic :-). So +0.
What do others think about the name?

Regards

Rüdiger


My 2c, on all proposals (and 2 variations):

-1:
AP_BUCKET_IS_MORPHING
AP_BUCKET_IS_OPAQUE
AP_BUCKET_DETERMINATE_LENGTH

+1:
AP_BUCKET_HAS_LENGTH
AP_BUCKET_HAS_UNKNOWN_LENGTH
AP_BUCKET_UNKNOWN_LENGTH
AP_BUCKET_LENGTH_UNKNOWN

CJ



Re: svn commit: r1875853 - /httpd/httpd/trunk/docs/manual/mod/mod_md.xml

2020-03-29 Thread Marion &amp; Christophe JAILLET

Ouch.

Sorry about that.

I was pretty sure that doc was re-built on my system, before submitting.
Don't know I did wrong.

CJ

Le 29/03/2020 à 15:09, cove...@apache.org a écrit :

Author: covener
Date: Sun Mar 29 13:09:41 2020
New Revision: 1875853

URL: http://svn.apache.org/viewvc?rev=1875853=rev
Log:
duplicated

[skip ci]

Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_md.xml

Modified: httpd/httpd/trunk/docs/manual/mod/mod_md.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_md.xml?rev=1875853=1875852=1875853=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_md.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_md.xml Sun Mar 29 13:09:41 2020
@@ -1240,7 +1240,6 @@ MDMessageCmd /etc/apache/md-message
  
  MDActivationDelay duration
  
-
  server config
  
  Available in version 2.4.42 and later




Re: svn commit: r1874545 - /httpd/httpd/trunk/modules/filters/mod_brotli.c

2020-02-26 Thread Marion &amp; Christophe JAILLET



Le 26/02/2020 à 18:47, gbec...@apache.org a écrit :

Author: gbechis
Date: Wed Feb 26 17:47:53 2020
New Revision: 1874545

URL: http://svn.apache.org/viewvc?rev=1874545=rev
Log:
Avoid printing NULL strings in logs

Modified:
 httpd/httpd/trunk/modules/filters/mod_brotli.c

Modified: httpd/httpd/trunk/modules/filters/mod_brotli.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_brotli.c?rev=1874545=1874544=1874545=diff
==
--- httpd/httpd/trunk/modules/filters/mod_brotli.c (original)
+++ httpd/httpd/trunk/modules/filters/mod_brotli.c Wed Feb 26 17:47:53 2020
@@ -419,7 +419,7 @@ static apr_status_t compress_filter(ap_f
  }
  q = ap_get_token(r->pool, , 1);
  ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r,
-  "token: '%s' - q: '%s'", token, q);
+  "token: '%s' - q: '%s'", token ?: "NULL", q);


Is this syntax standard? This looks like a GNU extension.

Shouldn't we use
   token ? token : "NULL"
instead?

A few google search make me think that it could be an issue with VS 
(i.e. windows build)


Just my 2c.

CJ



  }
  
  /* No acceptable token found or q=0 */





Re: svn commit: r1874007 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_util_ocsp.c

2020-02-14 Thread Marion &amp; Christophe JAILLET

Hi,

purely speculative, but does a:
   apr_table_set(headers, "Connection", "close");

around line 812 of md_oscp.c also makes sense?

CJ

Le 14/02/2020 à 10:38, rpl...@apache.org a écrit :

Author: rpluem
Date: Fri Feb 14 09:38:12 2020
New Revision: 1874007

URL: http://svn.apache.org/viewvc?rev=1874007=rev
Log:
* modules/ssl/ssl_util_ocsp.c (serialize_request): Set the Connection header
   to close to indicate that we do not want to keep the HTTP connection to the
   OCSP responder alive. We don't reuse the connections currently and if the
   OCSP responder keeps the connection alive this could cause us to wait for
   keepalive timeout of the OCSP responder to timeout until we finish our
   reading of the OCSP response.

PR: 64135


Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1874007=1874006=1874007=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Fri Feb 14 09:38:12 2020
@@ -1,6 +1,9 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.1
  
+  *) mod_ssl: Do not keep connections to OCSP responders alive when doing

+ OCSP requests.  PR 64135.  [Ruediger Pluem]
+
*) mod_ssl: Disable client verification on ACME ALPN challenges. Fixes 
github
   issue mod_md#172 (https://github.com/icing/mod_md/issues/172).
   [Michael Kaufmann , Stefan Eissing]

Modified: httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c?rev=1874007=1874006=1874007=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c Fri Feb 14 09:38:12 2020
@@ -46,6 +46,7 @@ static BIO *serialize_request(OCSP_REQUE
  BIO_printf(bio, "%s%s%s HTTP/1.0\r\n"
 "Host: %s:%d\r\n"
 "Content-Type: application/ocsp-request\r\n"
+   "Connection: close\r\n"
 "Content-Length: %d\r\n"
 "\r\n",
 uri->path ? uri->path : "/",




Re: svn commit: r1874011 - /httpd/httpd/trunk/server/mpm/event/event.c

2020-02-14 Thread Marion &amp; Christophe JAILLET

Hi,

The same code exists in 'worker', should it be fixed as well?

CJ

Le 14/02/2020 à 11:47, jor...@apache.org a écrit :

Author: jorton
Date: Fri Feb 14 10:47:36 2020
New Revision: 1874011

URL: http://svn.apache.org/viewvc?rev=1874011=rev
Log:
* server/mpm/event/event.c (event_open_logs): Avoid UBSan exception
   calling memcpy(,NULL,0) at startup.  Thanks to rpluem.

Modified:
 httpd/httpd/trunk/server/mpm/event/event.c

Modified: httpd/httpd/trunk/server/mpm/event/event.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=1874011=1874010=1874011=diff
==
--- httpd/httpd/trunk/server/mpm/event/event.c (original)
+++ httpd/httpd/trunk/server/mpm/event/event.c Fri Feb 14 10:47:36 2020
@@ -3616,8 +3616,9 @@ static int event_open_logs(apr_pool_t *
  new_max = num_buckets;
  }
  new_ptr = (int *)apr_palloc(ap_pglobal, new_max * sizeof(int));
-memcpy(new_ptr, retained->idle_spawn_rate,
-   retained->mpm->num_buckets * sizeof(int));
+if (retained->idle_spawn_rate) /* NULL at startup */
+memcpy(new_ptr, retained->idle_spawn_rate,
+   retained->mpm->num_buckets * sizeof(int));
  retained->idle_spawn_rate = new_ptr;
  retained->mpm->max_buckets = new_max;
  }




Re: the demo code can't run normally in apache 2.4.

2020-02-06 Thread Marion &amp; Christophe JAILLET


Le 07/02/2020 à 01:23, suisou a écrit :

hi,all.

I am a fresh .

my server version
Server version: Apache/2.4.37 (centos)
Server built:   Dec 23 2019 20:45:34.

httpd.x86_64 2.4.37-16.module_el8.1.0+256+ae790463 @AppStream
httpd-devel.x86_64 2.4.37-16.module_el8.1.0+256+ae790463 @AppStream
httpd-filesystem.noarch  2.4.37-16.module_el8.1.0+256+ae790463 @AppStream
httpd-tools.x86_64 2.4.37-16.module_el8.1.0+256+ae790463 @AppStream
apr.x86_64                          1.6.3-9.el8                @AppStream
apr-devel.x86_64                    1.6.3-9.el8                @AppStream
apr-util.x86_64                     1.6.1-6.el8                @AppStream
apr-util-bdb.x86_64                 1.6.1-6.el8                @AppStream
apr-util-devel.x86_64               1.6.1-6.el8                @AppStream
apr-util-openssl.x86_64             1.6.1-6.el8                @AppStream
audit.x86_64 3.0-0.10.20180831git0047a6c.el8       @anaconda



the code in chapter


  Retrieve variables from POST form data

from http://httpd.apache.org/docs/current/en/developer/modguide.html 
can't get the right respone.

i CHECK it step by step ,and found that
this row  not work .
 kvp[i].key = apr_pstrdup(r->pool, pair->name);

Is this a bug?

thanks.


Hi, suisou,

could you elaborate on what you mean by "not work" and "can't get the 
right response"?

What do you expect, what do you get?

CJ



Fwd: t/modules/{brotli,deflate}.t: handle the case < 2.4.42

2019-12-19 Thread Marion &amp; Christophe JAILLET

Hi,

I've received the attached patch against the test framework.
This is not the first time Petr propose such patches and most (or maybe 
even all) have been merged.


The goal is to avoid new warnings on suse tests when a recent test 
framework is used on an older version of httpd.


However, this particular case puzzles me.
I see r1868313 as a fix on a non-RFC compliant behavior. So I'm not sure 
this should be "hidden" only because older versions are known to fail.


In other word, what is the "semantic" behind the test framework?
   - Testing against regression only? (in this case including Petr's 
patch makes sense to me)   - or -
   - Checking that the behavior is correct (in this case, I'm not fan 
of "hiding" things that are known to fail. A failure would mean: "you 
should upgrade to have this fixed")


What is your opinion?

CJ

 Message transféré 
Sujet : t/modules/{brotli,deflate}.t: handle the case < 2.4.42
Date :  Tue, 17 Dec 2019 13:52:08 +0100
De :pgajdos 
Pour :  christophe.jail...@wanadoo.fr



Hello Christophe,

I just updated to httpd-framework r1870094 and it is failing for me in
brotli.t and deflate.t and it is because of r1868312 which assumes
that httpd-trunk r1868313 is included in the httpd (2.4.42 and on).

I tried to do something in the patch attached, but not sure it is
satisfactory for inclusion.

Bye,
Petr

--
Have a lot of fun!

Index: httpd-framework/t/modules/brotli.t
===
--- httpd-framework.orig/t/modules/brotli.t	2019-12-16 10:22:18.570687529 +0100
+++ httpd-framework/t/modules/brotli.t	2019-12-16 15:04:43.043442458 +0100
@@ -5,16 +5,22 @@ use Apache::Test;
 use Apache::TestUtil;
 use Apache::TestRequest;
 
+my $with_contenc=1;
+if (have_min_apache_version('2.4.42')) {
+  # httpd-trunk r1868313 not included
+  $with_contenc=0;
+}
+
 my @qvalue = (
 [ ''  , 1],
 [ ' ' , 1],
 [ ';' , 1],
 [';q=', 1],
-[';q=0'   , 0],
-[';q=0.'  , 0],
-[';q=0.0' , 0],
-[';q=0.00', 0],
-[';q=0.000'   , 0],
+[';q=0'   , $with_contenc],
+[';q=0.'  , $with_contenc],
+[';q=0.0' , $with_contenc],
+[';q=0.00', $with_contenc],
+[';q=0.000'   , $with_contenc],
 [';q=0.'  , 1],   # invalid qvalue format
 );
 
Index: httpd-framework/t/modules/deflate.t
===
--- httpd-framework.orig/t/modules/deflate.t	2019-12-16 10:22:18.570687529 +0100
+++ httpd-framework/t/modules/deflate.t	2019-12-16 15:04:43.043442458 +0100
@@ -56,7 +56,12 @@ for my $server_deflate_uri (@server_defl
  content => $deflated_str);
 
 ok $original_str eq $inflated_str;
-ok $original_str eq $deflated_str_q0;
+if (have_min_apache_version("2.4.42")) {
+  ok $original_str eq $deflated_str_q0;
+} else {
+  # httpd-trunk r1868313 not included
+  ok $deflated_str eq $deflated_str_q0;
+}
 my $resp = POST($server_inflate_uri, @inflate_headers,
 content => "foo123456789012346");
 if (have_min_apache_version("2.5")) {



Re: AW: Integration tests running on Docker

2019-11-07 Thread Marion &amp; Christophe JAILLET

Le 07/11/2019 à 11:31, Pluem, Ruediger, Vodafone Group a écrit :

C2 General


-Ursprüngliche Nachricht-
Von: Yann Ylavic 
Gesendet: Donnerstag, 7. November 2019 11:19
An: httpd-dev 
Betreff: Re: Integration tests running on Docker

On Wed, Nov 6, 2019 at 6:54 PM Joe Orton  wrote:

Has anybody seen t/modules/deflate.t and t/modules/brotli.t fail on
Debian-ish distro? I don't remember seeing this before but maybe it's

something

trivial?  t/TEST output -

It seems to originate from r1868312.

I don't really understand this new test in mod_deflate (the one which
fails):
 ok $original_str eq $deflated_str_q0;

Why would we expect a plain string to be equal to a deflated one,
Christophe?
I don't see how the failure depends on debian vs any other system
either.

Running t/modules/deflate.t on my debian, with this debugging patch:
```
Index: t/modules/deflate.t
===
--- t/modules/deflate.t (revision 1869498)
+++ t/modules/deflate.t (working copy)
@@ -57,6 +57,10 @@ for my $server_deflate_uri (@server_deflate_uris)

  ok $original_str eq $inflated_str;
  ok $original_str eq $deflated_str_q0;
+if (not $original_str eq $deflated_str_q0) {
+print "original: '$original_str'\n";
+print "deflated: '$deflated_str_q0'\n";
+}
  my $resp = POST($server_inflate_uri, @inflate_headers,
  content => "foo123456789012346");
  if (have_min_apache_version("2.5")) {
```

I get (e.g.):
```
not ok 42
original: '
Some dummy content. Some dummy content. Some dummy content. Some dummy
content.
EOF
'
deflated: '
I suspect that $deflated_str_q0 is the result of the request with 
Accept-Encoding: gzip;q=0
where mod_deflate actually should not gzip the response because of q=0.


Yeap, that's it



Regards

Rüdiger


Re: svn commit: r1869392 - in /httpd/httpd/trunk: CHANGES modules/md/md_acme.c modules/md/md_acme_drive.c modules/md/md_curl.c modules/md/md_http.c modules/md/md_version.h modules/md/mod_md_config.c

2019-11-05 Thread Marion &amp; Christophe JAILLET



Le 05/11/2019 à 16:04, ic...@apache.org a écrit :

Author: icing
Date: Tue Nov  5 10:06:15 2019
New Revision: 1869392

URL: http://svn.apache.org/viewvc?rev=1869392=rev
Log:
   *) mod_md v2.2.3:
  - Configuring MDCAChallenges replaces any previous existing challenge 
configuration. It
had been additive before which was not the intended behaviour. [@mkauf]
  - Fixing order of ACME challenges used when nothing else configured. Code 
now behaves as
documented for `MDCAChallenges`. Fixes #156. Thanks again to @mkauf for 
finding this.
  - Fixing a potential, low memory null pointer dereference [thanks to 
@uhliarik].
  - Fixing an incompatibility with a change in libcurl v7.66.0 that added 
unwanted
"transfer-encoding" to POST requests. This failed in directy 
communication with
Let's Encrypt boulder server. Thanks to @mkauf for finding and fixing.


Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/modules/md/md_acme.c
 httpd/httpd/trunk/modules/md/md_acme_drive.c
 httpd/httpd/trunk/modules/md/md_curl.c
 httpd/httpd/trunk/modules/md/md_http.c
 httpd/httpd/trunk/modules/md/md_version.h
 httpd/httpd/trunk/modules/md/mod_md_config.c

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1869392=1869391=1869392=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Tue Nov  5 10:06:15 2019
@@ -1,5 +1,15 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.1
+
+  *) mod_md v2.2.3:
+ - Configuring MDCAChallenges replaces any previous existing challenge 
configuration. It
+   had been additive before which was not the intended behaviour. [@mkauf]
+ - Fixing order of ACME challenges used when nothing else configured. Code 
now behaves as
+   documented for `MDCAChallenges`. Fixes #156. Thanks again to @mkauf for 
finding this.
+ - Fixing a potential, low memory null pointer dereference [thanks to 
@uhliarik].
+ - Fixing an incompatibility with a change in libcurl v7.66.0 that added 
unwanted
+   "transfer-encoding" to POST requests. This failed in directy 
communication with
+   Let's Encrypt boulder server. Thanks to @mkauf for finding and fixing. 
[Stefan Eissing]
  
*) mod_proxy: Put mod_proxy_{connect,wstunnel} tunneling code in common in

   proxy_util.  [Yann Ylavic]

Modified: httpd/httpd/trunk/modules/md/md_acme.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/md/md_acme.c?rev=1869392=1869391=1869392=diff
==
--- httpd/httpd/trunk/modules/md/md_acme.c (original)
+++ httpd/httpd/trunk/modules/md/md_acme.c Tue Nov  5 10:06:15 2019
@@ -402,7 +402,7 @@ static apr_status_t md_acme_req_send(md_
  if (req->req_json) {
  body = apr_pcalloc(req->p, sizeof(*body));
  body->data = md_json_writep(req->req_json, req->p, 
MD_JSON_FMT_INDENT);
-if (!body->data) {
+if (!body) {
  rv = APR_EINVAL; goto leave;


This revert r1869018 that I committed on trunk a few days ago.
Not sure if my fix was correct, but in r1869018 this code was changed.
Before we were checking the result of 'md_json_writep()' stored in 
'data', but now the retune valued is stored in 'body->data', so updating 
the check accordingly makes sense to me.


Just my 2c.


CJ



Re: httpd 2.4 and maintainer-mode

2019-10-14 Thread Marion &amp; Christophe JAILLET



Le 14/10/2019 à 17:15, Jim Jagielski a écrit :



On Oct 10, 2019, at 2:49 PM, Marion & Christophe JAILLET 
 wrote:

I guess that my version of GCC (i.e. 8.3.0) tolerates some c89 deviation in .h files 
included from "outside".

So you aren't using Xcode and clang?



No, just some comand line tools, some scripts, gcc and Geany as an IDE.

CJ



Re: httpd 2.4 and maintainer-mode

2019-10-10 Thread Marion &amp; Christophe JAILLET

Hi,

not a libxml guru at all, but looking at 
/usr/local/include/libxml2/libxml/encoding.h:31 (taken from your 
compilation warnings)


    #ifdef LIBXML_ICONV_ENABLED
    #include 
    #endif
    #ifdef LIBXML_ICU_ENABLED
    #include 
    #endif

and on my system:

    cd usr/include/

    find . -name iconv.h
    ./iconv.h

    find . -name ucnv.h
    ./unicode/ucnv.h

So, both are there.
And 'unicode/ucnv.h' has some // at its very beginning.


In order to confirm, I've manually modified  to generate 
some error. It IS parsed in my build.

However, when unmodified, no error or warning is generated.

If I remove the workaround at the beginning of mod_xml2enc.c, it also 
compiles without any issue at all.



Looking at this workaround, I don't think it is correct.
According to latest gcc doc, Wcomment is described as:

    Warn whenever a comment-start sequence ‘/*’ appears in a ‘/*’ 
comment, or whenever a backslash-newline appears in a ‘//’ comment. This 
warning is enabled by -Wall.


Apparently nothing to do with accepting or not // (in c89 in our case)


Adding a // within the "protected" block in mod_xml2enc.c leads to:
mod_xml2enc.c:36:1: error: C++ style comments are not allowed in ISO C90
 //

This confirms that the workaround does not what is expected.


I guess that my version of GCC (i.e. 8.3.0) tolerates some c89 deviation 
in .h files included from "outside".



CJ


Le 10/10/2019 à 18:05, Jim Jagielski a écrit :

And this is with maintainer-mode? I'm wondering why your setup is either OK w/ 
the C++ style comments or maybe Homebrew changes the comment style??


On Oct 10, 2019, at 8:33 AM, Stefan Eissing  
wrote:

When will I learn to read mails completely?

- Ok, proxy-html is not build by default, which explains the happiness due to 
ignorance.
- Once enabled, it does not find libxml2 (I think MacOS Vista removed it)
- brew reinstall libxml2
- configure   --with-libxml2=/usr/local/opt/libxml2

and it builds on my machine.

- Stefan


Am 10.10.2019 um 14:10 schrieb Jim Jagielski :

I am using MacPorts libxml2. But the issue seems to be w/ libxml2 itself; it is 
the package that uses the '//' comment style. Where does your build grab its 
xml2 stuff from?


On Oct 10, 2019, at 3:58 AM, Stefan Eissing  
wrote:

Compiling trunk and 2.4.x under MacOS Vista, no issues. Some homebrew install?


Am 09.10.2019 um 19:04 schrieb Marion & Christophe JAILLET 
:

Hi Jim,

I always compile (and test) with --enable-maintainer-mode.

I've just updated my 2.4 branch / make clean / make, and there is nothing 
special.

Any specific issue?

CJ


Le 09/10/2019 à 15:33, Jim Jagielski a écrit :

Anyone else trying to build HEAD of httpd-2.4 with --enable-maintainer-mode?





Re: httpd 2.4 and maintainer-mode

2019-10-09 Thread Marion &amp; Christophe JAILLET

Hi Jim,

I always compile (and test) with --enable-maintainer-mode.

I've just updated my 2.4 branch / make clean / make, and there is 
nothing special.


Any specific issue?

CJ


Le 09/10/2019 à 15:33, Jim Jagielski a écrit :

Anyone else trying to build HEAD of httpd-2.4 with --enable-maintainer-mode?



Re: svn commit: r1864868 - /httpd/httpd/trunk/server/core_filters.c

2019-08-10 Thread Marion &amp; Christophe JAILLET

Hi all,

I would appreciate some other eyes on the patch below.
I guess that that the fix is correct, but I don't know the possible 
implication of the fix.


As said in the commit description, -1 seems to be a valid length, but I 
don't know if such buckets can happen here.


So this patch can change the behavior of the code and trigger a path 
that was never executed before.

Comments from s.o. with deeper understanding of filters are welcomed.


Should the commit description be tweaked, please do so.

CJ


Le 10/08/2019 à 11:52, jaillet...@apache.org a écrit :

Author: jailletc36
Date: Sat Aug 10 09:52:34 2019
New Revision: 1864868

URL: http://svn.apache.org/viewvc?rev=1864868=rev
Log:
Fix a signed/unsigned comparison that can never match.

-1 is a valid length value (for socket, pipe and cgi buckets for example)
All path I've checked cast the -1 to (apr_size_t) in order for the comparison 
to work. So do it as well here.

This has been like that in trunk since r708144, about 11 years ago, so I assume 
that it is not really an issue.

Spotted by gcc 9.1 and -Wextra

Modified:
 httpd/httpd/trunk/server/core_filters.c

Modified: httpd/httpd/trunk/server/core_filters.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core_filters.c?rev=1864868=1864867=1864868=diff
==
--- httpd/httpd/trunk/server/core_filters.c (original)
+++ httpd/httpd/trunk/server/core_filters.c Sat Aug 10 09:52:34 2019
@@ -277,7 +277,7 @@ apr_status_t ap_core_input_filter(ap_fil
  while ((len < readbytes) && (rv == APR_SUCCESS)
 && (e != APR_BRIGADE_SENTINEL(ctx->bb))) {
  /* Check for the availability of buckets with known length */
-if (e->length != -1) {
+if (e->length != (apr_size_t)-1) {
  len += e->length;
  e = APR_BUCKET_NEXT(e);
  }





Re: svn commit: r1864735 - /httpd/httpd/branches/2.4.x/modules/http2/h2_stream.c

2019-08-08 Thread Marion &amp; Christophe JAILLET

Thx for spotting and fixing it Eric.

The comma has been automagically removed by 'make update-log-msg-tags'
Will have a look to see if i tweak the script in order to avoid that in 
the future.


CJ


Le 08/08/2019 à 23:23, cove...@apache.org a écrit :

Author: covener
Date: Thu Aug  8 21:23:29 2019
New Revision: 1864735

URL: http://svn.apache.org/viewvc?rev=1864735=rev
Log:
followup to r1864734

Modified:
 httpd/httpd/branches/2.4.x/modules/http2/h2_stream.c

Modified: httpd/httpd/branches/2.4.x/modules/http2/h2_stream.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/http2/h2_stream.c?rev=1864735=1864734=1864735=diff
==
--- httpd/httpd/branches/2.4.x/modules/http2/h2_stream.c (original)
+++ httpd/httpd/branches/2.4.x/modules/http2/h2_stream.c Thu Aug  8 21:23:29 
2019
@@ -783,7 +783,7 @@ apr_status_t h2_stream_end_headers(h2_st
  apr_table_do(table_check_val_len, , stream->request->headers, 
NULL);
  if (ctx.failed_key) {
  ap_log_cerror(APLOG_MARK, APLOG_INFO, 0, stream->session->c,
-  H2_STRM_LOG(APLOGNO(10190) stream,"Request header exceeds 
"
+  H2_STRM_LOG(APLOGNO(10190), stream,"Request header 
exceeds "
"LimitRequestFieldSize: %.*s"),
(int)H2MIN(strlen(ctx.failed_key), 80), 
ctx.failed_key);
  set_error_response(stream, HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE);





Re: svn commit: r1863484 - in /httpd/httpd/branches/2.4.x/docs/manual/mod: directives.html.fr.utf8 overrides.html overrides.xml.meta quickreference.html.fr.utf8

2019-07-20 Thread Marion &amp; Christophe JAILLET

Hi Lucien,

overrides.html.fr.utf8 seems to be missing in the commit.

CJ

Le 20/07/2019 à 18:01, lgen...@apache.org a écrit :

Author: lgentis
Date: Sat Jul 20 16:01:30 2019
New Revision: 1863484

URL: http://svn.apache.org/viewvc?rev=1863484=rev
Log:
fr doc rebuild.

Modified:
 httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8
 httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.html
 httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.xml.meta
 httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.fr.utf8

Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8?rev=1863484=1863483=1863484=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8 [utf-8] 
(original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/directives.html.fr.utf8 [utf-8] 
Sat Jul 20 16:01:30 2019
@@ -421,20 +421,28 @@
  MDCAChallenges
  MDCertificateAgreement
  MDCertificateAuthority
+MDCertificateFile
+MDCertificateKeyFile
  MDCertificateProtocol
+MDCertificateStatus
+MDChallengeDns01
  MDDriveMode
  MDHttpProxy
  MDMember
  MDMembers
+MDMessageCmd
  MDMustStaple
  MDNotifyCmd
  MDomain
  MDomainSet
  MDPortMap
  MDPrivateKeys
+MDRenewMode
  MDRenewWindow
  MDRequireHttps
+MDServerStatus
  MDStoreDir
+MDWarnWindow
  MemcacheConnTTL
  MergeSlashes
  MergeTrailers

Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.html
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.html?rev=1863484=1863483=1863484=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.html (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.html Sat Jul 20 
16:01:30 2019
@@ -3,3 +3,7 @@
  URI: overrides.html.en
  Content-Language: en
  Content-type: text/html; charset=ISO-8859-1
+
+URI: overrides.html.fr.utf8
+Content-Language: fr
+Content-type: text/html; charset=UTF-8

Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.xml.meta
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.xml.meta?rev=1863484=1863483=1863484=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.xml.meta (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/overrides.xml.meta Sat Jul 20 
16:01:30 2019
@@ -8,5 +8,6 @@
  


  en
+fr

  

Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.fr.utf8
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.fr.utf8?rev=1863484=1863483=1863484=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.fr.utf8 
[utf-8] (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/quickreference.html.fr.utf8 
[utf-8] Sat Jul 20 16:01:30 2019
@@ -862,23 +862,32 @@ inactifs
  MaxSpareThreads 
nombresMNombre maximum de threads 
inactifs
  MaxThreads nombre 2048 
sMDéfinit le nombre maximum de threads esclaves
  MDBaseServer on|off off 
sEControl if base server may be managed or only virtual 
hosts.
-MDCAChallenges name [ name ... ] tls-sni-01 http-01 
sEType of ACME challenge used to prove domain ownership.
-MDCertificateAgreement 
url-of-terms-of-servicesEThe URL 
of the Terms-of-Service document, that the CA server requires you to accept.
-MDCertificateAuthority url https://acme-v01.ap 
+sEThe URL of the ACME Certificate Authority service.
+MDCAChallenges name [ name ... ] tls-alpn-01 http-01 
+sEType of ACME challenge used to prove domain ownership.
+MDCertificateAgreement 
acceptedsEYou confirm that you 
accepted the Terms of Service of the Certificate
+Authority.
+MDCertificateAuthority url https://acme-v02.ap 
+sEThe URL of the ACME Certificate Authority service.
+MDCertificateFile 
path-to-pem-filesESpecify a static 
certificate file for the MD.
+MDCertificateKeyFile 
path-to-filesESpecify a static private key 
for for the static cerrtificate.
  MDCertificateProtocol protocol ACME 
sEThe protocol to use with the Certificate Authority.
-MDDriveMode always|auto|manual auto 
sEControl when it is allowed to obtain/renew 
certificates.
+MDCertificateStatus on|off on 
sEExposes public certificate information in JSON.
+MDChallengeDns01 
path-to-commandsE-
+MDDriveMode always|auto|manual auto 
sEformer name of MDRenewMode.
  MDHttpProxy 
urlsEDefine a proxy for outgoing 
connections.
  MDMember hostnamesEAdditional hostname for the managed domain.
  MDMembers auto|manual auto 
sEControl if the alias domain names are automatically 
added.
-MDMustStaple on|off off sEControl if new certificates carry the OCSP Must Staple flag.

Re: release?

2019-07-20 Thread Marion &amp; Christophe JAILLET

Hi,

PR60757 and corresponding r1853560 could be a good candidate for backport.

I don't have a configuration for testing so I won't propose it myself 
for backport, but the patch looks simple.


CJ

Le 18/07/2019 à 16:06, Stefan Eissing a écrit :

It would be great if we could make a release this month. There are several 
fixes and improvements already backported and a few outstanding issues that 
need a vote or two.

Please have a look if you find the time. I think Daniel expressed willingness 
to RM this? That'd be great!

Cheers, Stefan


Re: [2.4.39] [mod_auth_form] [mod_session_crypto] Cookie management performance

2019-05-10 Thread Marion &amp; Christophe JAILLET

Hi,

have you checked the work in trunk related to 
"SessionExpiryUpdateInterval"? [1]


If you have the opportunity to compile and test the trunk version and 
report if it corresponds to your use case, it would be great.


If you want to have a look at the code itself, see [2].

Just my 2c,

CJ

[1]: 
https://httpd.apache.org/docs/trunk/mod/mod_session.html#sessionexpiryupdateinterval
[2]: 
http://svn.apache.org/viewvc?diff_format=h=revision=date=1709121


Le 10/05/2019 à 12:26, Vincent Deffontaines a écrit :

Greetings,

The root observation that makes me open this subject is the following :
Using mod_auth_form + encrypted cookies to manage a web application 
authentication gets httpd's auth cookie to be reset by the server at 
each and every authenticated request. On a website with a number of 
users x a number of requests, this gets quite a number of HMAC crypto 
cookie cyphering operations, which I guess could be reduced.


In order to debug this, I started running the attached configuration 
(it's pretty much just the most reduced setup to use the module 
combination, nothing fancy).
This setup does not enforce cookie encryption. When cookie are 
encrypted, I obviously just can notice they differ from a request to 
another. When they are not encrypted, I understand why.


Here are a few successive (ordered) cookies sent by the server with 
this configuration, including the dummy login and password I'm using 
for illustrating this matter :


Set-Cookie: 
DMS-tags-session=DMS-TAG+-+File+Auth-user=login+-+File+Auth-pw=pass=1557494869445278;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1


Set-Cookie: 
DMS-tags-session=DMS-TAG+-+File+Auth-user=login+-+File+Auth-pw=pass=1557494870169716;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1


Set-Cookie: 
DMS-tags-session=DMS-TAG+-+File+Auth-user=login+-+File+Auth-pw=pass=1557494870865331;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1


The most interesting part is that, no matter how close in time these 
requests can be, the "expiry=%ld" part will change, because it is an 
epoch timestamp with a precision up to the microsecond.


I guess nothing here is wrong, regarding RFC2109. But it appeared odd 
to me, as opposed to the way most web sessions are dealt with : while 
our cookie lifetime definetely matches the MaxAge produced in 
configuration, it is nevertheless reset by the server at each request.


This is of no performance consequence in this debug setup, but I 
believe the load can be affected as soon as one sets a 
SessionCryptoPassphrase ).


For what it's worth, I have benched the difference on my (non-summy) 
application, by reloading the main page (which implies quite some 
applicative processing on the server, too, and loads 119 hits to 
generate the page).
When sessions are encrypted, for 10 refreshes of the page, I measure 
an average of 6.5s load time (min : 5.49s, max : 7.55s)
With non encrypted sessions, for 10 refreshes of the page, I measure 
an average of 5.9s load time (min : 4.87s, max : 7.13s)


My conclusion from this small bench is that the performance hit from 
encrypting each cookie is not insignifiant. It can be measured  and 
extracted.


One suggestion could be the following : trying to get the cookie not 
to be recomputed by chunks of time, maybe recompute it every 
(SessionMaxAge/3) ; maybe expose a directive to manage this delay ?



Additionnally, when setting SessionMaxAge to 0, the cookie expiry does 
not change anymore. But the Set-Cookie is still set with every 
request, which hints the server still computes the cookie encryption 
for each response generation.


I'd like to read your ideas about these possible optimizations.

Cheers,

Vincent



Re: [VOTE] Release httpd-2.4.39

2019-03-29 Thread Marion &amp; Christophe JAILLET


Le 27/03/2019 à 16:09, Daniel Ruggeri a écrit :

Hi, all;
   Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this 
candidate tarball as 2.4.39:

[ ] +1: It's not just good, it's good enough!
[X] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha1: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
sha256: 
8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30 
*httpd-2.4.39.tar.gz




Tested on Ubuntu 18.10, compiled with gcc 8.2.0.
Tested with event, prefork and worker.

I see some core dumps when using 'prefork' in the ssl tests.

   t/TEST t/ssl/

t/ssl/proxy.t .. ok
t/ssl/require.t  ok
t/ssl/v2.t . skipped: SSLv2 test(s) not applicable
t/ssl/varlookup.t .. 62/83 [  error] oh dangit, server dumped core
[  error] for stacktrace, run: gdb /home/tititou36/httpd-2.4/bin/httpd 
-core /home/tititou36/svn_test_framework/t/core

t/ssl/varlookup.t .. ok
t/ssl/verify.t . 1/3 [  error] oh dangnabit, server dumped core
[  error] for stacktrace, run: gdb /home/tititou36/httpd-2.4/bin/httpd 
-core /home/tititou36/svn_test_framework/t/core

t/ssl/verify.t . ok

Each time I run the test framework it ends with a core dumps during ssl 
tests, but not always on the same test.

I've NOT spotted any issue with the other MPM.

It is likely a issue in my test environment, but I've never seen it before.


Could others confirm that they have tested with 'prefork' and that they 
don't have any issue?



Test coverage data from my test environment attached.

CJ

Title: HTTPd Test Coverage



  
  

 
  

  
  
  
  
   
HTTPd Test Coverage
   
  
  
   
This should give us some idea of how well our test-framework actually stress our
code.


   

mod_access_compat
81.94% tested


mod_allowmethods
89.36% tested


mod_auth_basic
55.79% tested


mod_auth_digest
53.87% tested


mod_auth_form
52.02% tested


mod_authn_anon
75.00% tested


mod_authn_core
37.27% tested


mod_authn_dbd
8.55% tested


mod_authn_dbm
22.22% tested


mod_authn_file
85.48% tested


mod_authn_socache
16.38% tested


mod_authnz_fcgi
3.72% tested


mod_authz_core
60.00% tested


mod_authz_dbd
6.47% tested


mod_authz_dbm
13.13% tested


mod_authz_groupfile
62.50% tested


mod_authz_host
14.29% tested


mod_authz_owner
7.14% tested


mod_authz_user
33.33% tested


mod_unixd
28.97% tested


mod_isapi
0.00% tested


cache_storage
36.46% tested


cache_util
41.47% tested


mod_cache_disk
65.26% tested


mod_cache
41.65% tested


mod_cache_socache
60.29% tested


mod_file_cache
18.80% tested


mod_socache_dbm
1.43% tested


mod_socache_memcache
4.86% tested


mod_socache_shmcb
43.46% tested


mod_heartbeat
16.25% tested


mod_heartmonitor
6.22% tested


mod_macro
0.00% tested


mod_watchdog
66.19% tested


mod_dbd
12.60% tested


dbm
22.44% tested


lock
57.92% tested


mod_dav_fs
66.67% tested


repos
34.00% tested


locks
0.00% tested


mod_dav_lock
23.81% tested


liveprop
89.58% tested


mod_dav
22.20% tested


props
44.19% tested


providers
33.33% tested


std_liveprop
43.75% tested


util
41.75% tested


util_lock
57.81% tested


mod_bucketeer
87.10% tested


mod_dumpio
21.33% tested


mod_echo
89.87% tested


mod_case_filter
86.49% tested


mod_case_filter_in
83.72% tested


mod_example_hooks
0.00% tested


mod_example_ipc
0.00% tested


mod_brotli
53.33% tested


mod_buffer
69.75% tested


mod_charset_lite
6.47% tested


mod_data
72.15% tested


mod_deflate
41.45% tested


mod_ext_filter
59.66% tested


mod_filter
50.73% tested


mod_include
75.20% tested


mod_proxy_html
7.10% tested


mod_ratelimit
48.76% tested


mod_reflector
86.11% tested


mod_reqtimeout
60.24% tested


mod_request
13.10% tested


mod_sed
3.06% tested


mod_substitute
80.13% tested


mod_xml2enc
3.59% tested


regexp
0.00% tested


sed0
0.00% tested


sed1
0.00% tested


mod_asis
58.14% tested


mod_autoindex
42.69% tested


mod_cgid
74.51% tested


mod_cgi
8.19% tested


mod_info
83.73% tested


mod_status
66.74% tested


mod_suexec
65.71% tested


h2_alt_svc
19.23% tested


h2_bucket_beam
76.63% tested


h2_bucket_eos
74.29% tested


h2_config
40.44% tested


h2_conn
86.16% tested


h2_conn_io
85.71% tested


h2_ctx
100.00% tested


h2_filter
24.82% tested


h2_from_h1
26.55% tested


h2_h2
62.11% tested


h2_headers
61.76% tested


h2_mplx
65.98% tested


h2_proxy_session
0.00% tested


h2_proxy_util
0.00% tested


h2_push
11.19% tested


h2_request
61.33% tested


h2_session
57.76% tested


h2_stream
49.83% tested


h2_switch
56.94% tested


h2_task
59.45% tested


h2_util
45.75% tested


h2_workers
81.93% tested


mod_http2
75.86% tested


mod_proxy_http2
9.14% tested


mod_mime
49.39% tested


mod_log_config
41.66% tested


mod_log_debug
76.03% tested


mod_log_forensic
25.23% tested


mod_logio
64.29% tested


lua_apr

Re: svn commit: r1856208 - /httpd/test/framework/trunk/t/apache/mergeslashes.t

2019-03-26 Thread Marion &amp; Christophe JAILLET



Le 26/03/2019 à 22:52, Eric Covener a écrit :

# GET /authz_core/a/b/c//index.html HTTP/1.1\r\nHost:
merge-disabled\r\nConnection: close\r\n\r\n
# expected 200, got 403 for c// doesn't match locationmatch
not ok 7
# Test 7 got: "403" (t/apache/mergeslashes.t at line 73 fail #7)
#   Expected: "200" (c// doesn't match locationmatch)
Failed 1/7 subtests

Backported version is working OK for me too.  Thanks for the
reliability fix Joe.

Can you verify the 403 in  t/logs/error_log is a 'client denied by
server configuration' and that it goes away (but other tests break) if
you comment the 2nd-to last locationmatch in t/conf/core.conf?



Ok, I found my mistakes. (my 2.4.x SHOULD always be UN-modified, well, 
hmm, it wasn't...)


Everything is fine for me. Sorry for the noise.

CJ



Re: Regression?

2019-02-18 Thread Marion &amp; Christophe JAILLET



Le 18/02/2019 à 23:55, Gregg Smith a écrit :
When setting a header it used to set the header case-sensitive as 
configured. Now with 2.4.38 it sets in all lower case. Regression?


Header always set X-Xss-Protection "1; mode=block"
Result;
2.4.37: X-Xss-Protection: 1; mode=block
2.4.38: x-xss-protection: 1; mode=block

If I'm reading the RFC correctly, sensitivity doesn't matter when 
parsing the header but the 2.4 docs show it outputting as configured 
as 2.4 has been prior to .38.


Cheers

G


Hi,

Everything looks fine to me.
I'm currently working on extending headers.t in order to test things 
other than ('set', 'append', 'add', 'unset');


If I add a specific test for 'set', with 2.4.39(dev), I get the 
following log:


Header received n°0:
  header:   X-Xss-Protection
  expected: 1; mode=block
  received: 1; mode=block

Response received is:
HTTP/1.1 200 OK
Connection: close
Date: Tue, 19 Feb 2019 05:28:56 GMT
Accept-Ranges: bytes
ETag: "0-52169385a8a8a"
Server: Apache/2.4.39-dev (Unix) OpenSSL/1.1.1
Vary: In-If1
Content-Length: 0
Content-Type: text/html
Last-Modified: Tue, 06 Oct 2015 05:51:24 GMT
Client-Date: Tue, 19 Feb 2019 05:28:56 GMT
Client-Peer: 127.0.0.1:8529
Client-Response-Num: 1
DMMATCH1: 1
X-Xss-Protection: 1; mode=block

ok 372

So, the case looks good to me.


If it helps, I can provide the updated headers.t as-is.
It still needs more cases (and probably some perl syntax clean-up ).

I also plan to update the doc, at least about the 'echo' command.
Doc states that in 'echo' command,  'header' MAY be a regular 
expression. In fact it IS ALWAYS considered as a regex and "header echo 
x" echoes everything that has a 'x'. Should you want only 'x', 
apparently you need something like "header echo ^x$".



What do you mean by "the 2.4 docs show it outputting as configured as 
2.4 has been prior to .38"?


CJ


Re: svn commit: r32075 - /dev/httpd/ /release/httpd/

2019-01-21 Thread Marion &amp; Christophe JAILLET

Fixed in r32079.

I hope I did it right.

CJ

Le 21/01/2019 à 17:48, Marion et Christophe JAILLET a écrit :


s/September/January/

in the announcement (html and txt)

CJ

> Message du 21/01/19 16:03
> De : drugg...@apache.org
> A : c...@httpd.apache.org
> Copie à :
> Objet : svn commit: r32075 - /dev/httpd/ /release/httpd/
>
> Author: druggeri
> Date: Mon Jan 21 15:03:33 2019
> New Revision: 32075
>
> Log:
> Push 2.4.38 up to the release directory
>
> Added:
> release/httpd/CHANGES_2.4.38
> - copied unchanged from r32074, dev/httpd/CHANGES_2.4.38
> release/httpd/httpd-2.4.38.tar.bz2
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.bz2
> release/httpd/httpd-2.4.38.tar.bz2.asc
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.bz2.asc
> release/httpd/httpd-2.4.38.tar.bz2.md5
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.bz2.md5
> release/httpd/httpd-2.4.38.tar.bz2.sha1
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.bz2.sha1
> release/httpd/httpd-2.4.38.tar.bz2.sha256
> - copied unchanged from r32074,
dev/httpd/httpd-2.4.38.tar.bz2.sha256
> release/httpd/httpd-2.4.38.tar.gz
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz
> release/httpd/httpd-2.4.38.tar.gz.asc
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz.asc
> release/httpd/httpd-2.4.38.tar.gz.md5
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz.md5
> release/httpd/httpd-2.4.38.tar.gz.sha1
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz.sha1
> release/httpd/httpd-2.4.38.tar.gz.sha256
> - copied unchanged from r32074, dev/httpd/httpd-2.4.38.tar.gz.sha256
> Removed:
> dev/httpd/CHANGES_2.4
> dev/httpd/CHANGES_2.4.38
> dev/httpd/httpd-2.4.38-deps.tar.bz2
> dev/httpd/httpd-2.4.38-deps.tar.bz2.asc
> dev/httpd/httpd-2.4.38-deps.tar.bz2.md5
> dev/httpd/httpd-2.4.38-deps.tar.bz2.sha1
> dev/httpd/httpd-2.4.38-deps.tar.bz2.sha256
> dev/httpd/httpd-2.4.38-deps.tar.gz
> dev/httpd/httpd-2.4.38-deps.tar.gz.asc
> dev/httpd/httpd-2.4.38-deps.tar.gz.md5
> dev/httpd/httpd-2.4.38-deps.tar.gz.sha1
> dev/httpd/httpd-2.4.38-deps.tar.gz.sha256
> dev/httpd/httpd-2.4.38.tar.bz2
> dev/httpd/httpd-2.4.38.tar.bz2.asc
> dev/httpd/httpd-2.4.38.tar.bz2.md5
> dev/httpd/httpd-2.4.38.tar.bz2.sha1
> dev/httpd/httpd-2.4.38.tar.bz2.sha256
> dev/httpd/httpd-2.4.38.tar.gz
> dev/httpd/httpd-2.4.38.tar.gz.asc
> dev/httpd/httpd-2.4.38.tar.gz.md5
> dev/httpd/httpd-2.4.38.tar.gz.sha1
> dev/httpd/httpd-2.4.38.tar.gz.sha256
> Modified:
> release/httpd/Announcement2.4.html
> release/httpd/Announcement2.4.txt
> release/httpd/CHANGES_2.4
>
> Modified: release/httpd/Announcement2.4.html
>

==
> --- release/httpd/Announcement2.4.html (original)
> +++ release/httpd/Announcement2.4.html Mon Jan 21 15:03:33 2019
> @@ -49,15 +49,15 @@
>

>
>



  > - Apache HTTP Server 2.4.37 Released
  > + Apache HTTP Server 2.4.38 Released
  >


>

>
> - October 23, 2018
> + September 21, 2018
>


>

>
> The Apache Software Foundation and the Apache HTTP Server
Project are
> pleased to announce

> - the release of version 2.4.37 of the Apache
> + the release of version 2.4.38 of the Apache
> HTTP Server ("Apache"). This version of Apache is our latest GA
> release of the new generation 2.4.x branch of Apache HTTPD and
> represents fifteen years of innovation by the project, and is
> @@ -69,7 +69,7 @@
> encourage users of all prior versions to upgrade.
>


>

>
> - Apache HTTP Server 2.4.37 is available for download from:
> + Apache HTTP Server 2.4.38 is available for download from:
>


>

>
> @@ -77,7 +77,7 @@
> 


>

>
> Please see the CHANGES_2.4 file, linked from the download page,
for a
> - full list of changes. A condensed list, CHANGES_2.4.37
includes only
> + full list of changes. A condensed list, CHANGES_2.4.38
includes only
> those changes introduced since the prior 2.4 release. A summary
of all
> of the security vulnerabilities addressed in this and earlier
releases
> is available:
>
> Modified: release/httpd/Announcement2.4.txt
>

==
> --- release/httpd/Announcement2.4.txt (original)
> +++ release/httpd/Announcement2.4.txt Mon Jan 21 15:03:33 2019
> @@ -1,9 +1,9 @@
> - Apache HTTP Server 2.4.37 Released
> + Apache HTTP Server 2.4.38 Released
>
   

Re: Testing regime during httpd development/release

2019-01-13 Thread Marion &amp; Christophe JAILLET

Hi Nik,

There is no formal workflow advised to follow.
However, it is the responsibility of every committer to keep the code 
compile-able and run-able.



However, a few more explanations and precisions.

When some code is added/modified, it must be committed in trunk first.
trunk is a CTR branch. That means Commit Then Review.
You push first, then anyone can make some review and/or comment on the code.

If the code is considered good enough to be included in a new release, 
it has to be proposed for backport (see the STATUS file 
(http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?view=markup) 
for the current patches proposed for backport)

The other branches are RTC, that it to say Review Then Commit.

We need to have at least 3 +1 to backport the code.
Developers can comment, improve the proposal, raise potential issues, ...
One can also veto (-1) a patch and explain why.

Without any consensus, no backport is allowed.

You can also have some information at:
   https://httpd.apache.org/dev/
   https://httpd.apache.org/dev/guidelines.html#voting


In other words, before being included in a release, code:
   - should be tested and reviewed by its author
   - should be reviewed by other developers in trunk
   - *IS* reviewed *AND* *IS* tested by at least 3 different committers
   - *IS* tested by many people using the test framework discussed below
 is usually run on some early adopter websites
 is usually tested for some specific load/environment/configuration 
by some developers

 ... before being released as part of a new release


It is also welcomed to add some new test-cases when changes are made, 
bug fixed or new functionalities added.
Testing everything, every configuration, every environment and every 
potential interaction is impossible.
However, the more test we have, the more confident we can be with each 
new release.



We have 2 main test framework.
One is (should be) dedicated to unit test. It is available in the test 
directory of the trunk branch. Up to now, it is mostly a PoC. Nothing 
big is available yet.
At least an infrastructure is available if come contributors want to add 
some useful stuff.


The other test framework is a perl framework located, as you noted, at:
   - https://httpd.apache.org/test/
   - http://svn.apache.org/viewvc/httpd/test/framework/trunk/

mod_h2 also has its own framework located at 
http://svn.apache.org/viewvc/httpd/test/mod_h2/


This perl test framework is much more complete and useful.

Tests are run on several OS and configuration, depending of the 
individual running the test.

They are run at least before each new release and results are posted.
To give you an idea, here is a pointer on the last voting / testing 
thread before 2.4.37 release.

https://lists.apache.org/list.html?dev@httpd.apache.org:2018-10:httpd-2.4.37


I hope these few information are helpful for you and any contribution is 
greatly appreciated.
If unclear or incomplete, do not hesitate to ask again, you are on the 
right mailing list for that.


Best regards,

CJ


Le 13/01/2019 à 15:51, Nik Sultana a écrit :


Had sent this a month back but it might have languished in inboxes
during vacation season.

Basically is there any onboarding/advice/workflow for testing, or are
people left to their own (divergent/unchecked) devices?

Is there a more suitable httpd mailing list for this question?

Thanks,
Nik

On Thu, 13 Dec 2018, Nik Sultana wrote:


Hi all, I wonder how httpd devs go about testing their code before it's
committed -- is there a workflow that everybody's advised to follow, to
try and smoke out potential breakages early? I regularly see people
voting on this mailing list to make successive httpd releases, but it's
not clear to me what goes into the QA for release engineering.

I've been hacking some ideas locally into the Apache httpd source code
as part of a research project, and I usually test my changes by running
Apache Bench or other traffic generators on it. But I'm not sure how
well this compares with what Apache committers/testers do.

While looking around the Internet I came across this, which seems most
relevant:
   https://httpd.apache.org/test/
I'm not sure how up-to-date it is (e.g., the SPECWeb99 tests it
references have long since been retired).
Are the programs linked from that page the state-of-the-art for httpd
testing?

I also came across various other disparate advice on load testing of web
servers. Are there any systems that httpd devs find especially useful?

And finally, does httpd testing tend to be done on one or two machines
(by firing a traffic generator at httpd), or are there any cluster-based
testing systems that you've found to be useful for more
rigorous/expansive testing? (e.g., firing traffic from various machines
into an httpd instance.)0

I'm happy to compile your answers into documentation if you wish, perhaps
as a refresh of https://httpd.apache.org/test/

Best,
Nik


Re: Stale BZ Bug Tracker reports

2018-11-01 Thread Marion &amp; Christophe JAILLET


Le 31/10/2018 à 21:52, William A Rowe Jr a écrit :
There are 715 reports tagged 2.0.0 through 2.3-HEAD of Status NEW or 
NEEDINFO with no Resolution.


For these bugs I believe we should simply close them with a message 
that this is a mass-update, that the version is beyond EOL, and a 
request for reporters/observers to retest and reopen with the 
supported version number if they are still reproducible using a modern 
2.4.x version. But I can't determine the best Status/Resolution 
code... suggestions?


+1
IMHO, the best status would be CLOSED/WONTFIX. Maybe a new Keyword such 
as TooOldAndInactive to ease finding such mass-update?
Or ask for a new status TOO_OLD (but I'm not sure it would really be 
that useful)




There are 69 bugs of status REOPENED, and 20 of status ASSIGNED (?). 
These should likely be reviewed by hand and either ACCEPTED against 
2.4-HEAD, tagged NEEDINFO with a request to re-review (after 
mass-cleanup of NEEDINFO above), or closed as above with an invitation 
to retest and reopen.

+1, after by-hand review, as proposed.



There are 255 bugs of Status NEW from 2.4.1-2.4.17, releases which are 
over three years old. For these, the best resolution is probably NEEDINFO.

-1.
Not sure NEEDINFO is fine for these ones. We should set NEEDINFO after 
by hand review, if we NEEDINFO. Or close it if invalid, or leave it as 
is if it looks right but no one has looked at it.
The reporter has done his job. He has reported what he thinks is enough. 
WE should provide an answer or ask for more details.


And there are 38 2.4.x NEEDINFO bugs, most of which can likely be 
closed for good as INVALID under a manual review.

+1 if older than, let say, 1 year?
The number is small, they could also be doubled check by hand. But is is 
likely, that it would end as INVALID because the analysis has already 
been done, and the reporter does not seem to be interested to answer.




I'm thinking of generic comment which would read (2nd paragraph for 
2.0-2.3.x only);


"""
Please help us to refine our list of open and current defects. This is 
a mass update of older Bugzilla reports which reflect user error, 
already resolved defects, and still-existing defects in httpd.

[...]. This is a mass update of old and inactive reports [...]


As repeatedly announced, the Apache HTTP Server Project has 
discontinued all development and patch review of the 2.2.x series of 
releases. The final release 2.2.34 was published in July 2017, and no 
further evaluation of bug reports or security risks will be considered 
or published for 2.2.x releases.


If your report represented a question or confusion about how to use an 
httpd feature, an unexpected server behavior, problems building or 
installing httpd, or working with an external component (a third party 
module, browser etc.) we ask you to start by bringing your question to 
the User Support and Discussion mailing list, see 
[https://httpd.apache.org/lists.html#http-users] for details. Include 
a link to this Bugzilla report for completeness with your question.


If your report was clearly a defect in httpd, we ask that you retest 
using a modern httpd release (2.4.33 or later) released in the past 
year. If it can be reproduced, please reopen this bug and change the 
Version field above to the httpd version you have reconfirmed with.



[...] a defect in httpd or a feature request [...]

Your help in identifying only current defects in the httpd server 
software is greatly appreciated.

"""

Comments, suggestions and other feedback before we proceed to take a 
broad scythe to the stale reports?




We should also forbid bug report against 2.2.x.

CJ


Re: Test framework regressions - spelling and usertrack

2018-10-22 Thread Marion &amp; Christophe JAILLET




Le 22/10/2018 à 16:56, Jim Jagielski a écrit :

The latest update to usertrack works. Thx! speling still bad:

On httpd-2.4 HEAD:

   t/modules/speling.t . 1/48 # Failed test 11 in 
t/modules/speling.t at line 46 fail #6
   # Failed test 12 in t/modules/speling.t at line 50 fail #5
   # Failed test 35 in t/modules/speling.t at line 46 fail #18
   # Failed test 36 in t/modules/speling.t at line 50 fail #9
   t/modules/speling.t . Failed 4/48 subtests
(less 13 skipped subtests: 31 okay)

On trunk:

   t/modules/speling.t . 1/48 # Failed test 11 in 
t/modules/speling.t at line 46 fail #6
   # Failed test 12 in t/modules/speling.t at line 50 fail #5
   # Failed test 13 in t/modules/speling.t at line 46 fail #7
   # Failed test 14 in t/modules/speling.t at line 50 fail #6
   # Failed test 15 in t/modules/speling.t at line 46 fail #8
   # Failed test 16 in t/modules/speling.t at line 50 fail #7
   # Failed test 35 in t/modules/speling.t at line 46 fail #18
   # Failed test 36 in t/modules/speling.t at line 50 fail #9
   # Failed test 37 in t/modules/speling.t at line 46 fail #19
   # Failed test 38 in t/modules/speling.t at line 50 fail #10
   # Failed test 39 in t/modules/speling.t at line 46 fail #20
   # Failed test 40 in t/modules/speling.t at line 50 fail #11
   t/modules/speling.t . Failed 12/48 subtests
  (less 13 skipped subtests: 23 okay)

I've not tested on trunk :(.
It is expected to give some different result because of r1557580 which 
has changed the default behavior.
I plan to restore the previous behavior (just need to change the default 
value of 'check_basename_match', I think) and then propose for backport.

Consider this ~5 years few lines patch still a WIP...
(apologies for neither finishing, nor reverting the changes)


This is on macOS. The speling tests show:

# testing : Checking case. Expecting: 301
# expected: 301
# received: '200'
not ok 11
# testing : Redirect ok
# expected: qr/good\.html|several1\.html/
# received: 'If the system is not case-sensitive, it is likely that this test must be 
tweaked.



# Failed test 11 in t/modules/speling.t at line 46 fail #6
# Failed test 12 in t/modules/speling.t at line 50 fail #5
# testing : Checking wrong extension. Expecting: 300
# expected: 300
# received: '404'
not ok 13

This is the expected change of behavior.

CJ


Re: Test framework regressions - spelling and usertrack

2018-10-22 Thread Marion &amp; Christophe JAILLET




Le 22/10/2018 à 16:16, Rainer Jung a écrit :

Am 22.10.2018 um 15:45 schrieb Yann Ylavic:
On Mon, Oct 22, 2018 at 3:28 PM Yann Ylavic  
wrote:


On Mon, Oct 22, 2018 at 3:09 PM Jim Jagielski  wrote:


These are new from a coupla day ago:


Both tests were added a few days ago, so probably not a regression
(test issues likely).


FWIW, both pass on my Linux system.


Not here on Solaris. I think new r1844562 is the correct fix for 
usertrack.t.


New speling.t and session_cookie.t work here.

regards,

Rainer



Thx for fixing this "Perl syntax" issue.

This is strange because it worked fine as-is for me (Ubuntu)

CJ


Re: RESULT: Passed - [VOTE] Release httpd-2.4.35

2018-09-21 Thread Marion &amp; Christophe JAILLET

FYI, 2.4.35 version has been added to bz.

CJ


Le 21/09/2018 à 14:31, Daniel Ruggeri a écrit :

Hi, all;

    I am delighted to share that the vote to release Apache httpd-2.4.35
has PASSED. The following votes were recorded:

Binding +1:
minfrin, icing, jorton, gsmith, steffenal, covener, jailletc36, ylavic,
rjung, druggeri, wroewe

Community +1:
Noel Butler


I'd like to add that, as an RM, I am VERY pleased that we received 12
votes in only 3.5 days. I thank you for all the time you've put into
this project and into testing this release.

ANNOUNCE text will be updated a bit later today (with a note about
OpenSSL and upcoming TLS 1.3) and I've kicked off the dist sync process.

I will also plan to RM a followup release as promised now that the TLS
1.3 change has been merged... but let's give that a few weeks for other
features to make it into 2.4.x :-)





Re: [Bug 62318] healthcheck

2018-08-24 Thread Marion &amp; Christophe JAILLET

Yes, agreed.

CJ


Le 24/08/2018 à 18:05, Eric Covener a écrit :

On Fri, Aug 24, 2018 at 11:57 AM Christophe JAILLET
 wrote:

Le 24/08/2018 à 16:40, Jim Jagielski a écrit :

I was wondering if someone wanted to provide a sanity check
on the above PR and what's "expected" by the health check code.

It would be very easy to adjust so that hcinterval was not
the time between successive checks but the interval between
the end of one and the start of another, but I'm not sure that
is as useful. In other words, I think the current behavior
is right (but think the docs need to be updated), but am
willing to have my mind changed :)


Hi Jim,

the current behavior is also what I would expect.
If I configure a check every 10s, I would expect 6 checks each minute,
even if the test itself takes time to perform.


Bug describes something else IIUC.  Because the watchdog calls us 10
times per second, it continuously sees that the worker hasn't been
health checked within the desired interval and queues up a check, it
doesn't know one is queued.





Re: alias.t/extra.conf.in change 1829008

2018-08-21 Thread Marion &amp; Christophe JAILLET




Le 21/08/2018 à 15:27, pgajdos a écrit :

Hello Christophe,

On Mon, Aug 20, 2018 at 08:34:16PM +0200, Marion & Christophe JAILLET wrote:

according to https://httpd.apache.org/docs/2.4/en/mod/mod_alias.html#alias,
Alias with-in a LocationMatch is allowed since 2.4.19.
If you can test and confirm, I'll update the test-framework accordingly.

yes, as far as I tested correctly, this is true from 2.4.20 on, 2.4.19
was not released, so I can not test.


BTW, glad to see someone tweaking our test framework.
Feel free to send any improvements and/or additional tests. They will be
added to the base in order to improve future releases.

And I should say big thank you for the test suite. It helps me every
security update in regression testing.

For curiosity, there is a apache-test spec running the testsuite
during build (the package results in no rpm):
[0] https://build.opensuse.org/package/show/Apache:Test/apache-test
and therefore testing the httpd in respective distros. I have similar
setup in internal build service instance, where I am testing httpd
BEFORE and AFTER each security update in several distros.

For one example, from link [0], the testsuite is failing for
openSUSE Leap 42.3, and this is because we backported http_strict
things, but had not noticed
http://svn.apache.org/viewvc?view=revision=1800215
which we now found thanks to the testsuite and we will be releasing
update in near future to fix that.

You can notice from the [0], we have around twenty patches, but almost
all are dedicated to get around issues in older distros, like 'we
ported something to older distros', which the testsuite can not know.

One thing I noticed is insufficient version checking of httpd version,
Well, it is sometimes hard to figure out when a given feature or 
directive has been added. Especially when tests are added a long time 
afterwards. Well, it is not that hard, but it is time consuming and 
honestly, I don't really focus on old releases compatibility.

And as you say, 2.2 is no more supported by us, so...

Having more test is always needed and we consider that some work should 
be needed in this area.

Contributions welcome :)


The 'lbmethod=heartbeat' in 2.3.0+ has been fixed in r1838576.
The 'ProxyAddHeaders' in 2.3.10+ has been fixed in r1838578.

For 'SSLOCSPResponderCertificateFile' I've asked on the dev@ list if 
just skipping the directive is enough or if something else must be tweaked.



I've gone through [0] and applied what make sense to me. If you consider 
that something else could be backported (i.e. is not opensuse specific), 
do not hesitate to tell me what.


I'm also adding the dev@ list in copy, there is no need to keep this 
private. Others could be interested.


CJ



see attachments. Note we will still be supporting 2.2 branch for
certain amount of time in one of our distros, not sure though how much
the testsuite upstream should take it into account given that 2.2 is no
longer supported upstream. But at least SSLOCSPResponderCertificateFile
should be surrounded I think.

I have also issue with ocsp.t failing completely, but that needs more
investigation.

Thanks again for the great testsuite!

Petr





Re: We have soon 5 SVN repo's

2017-11-04 Thread Marion &amp; Christophe JAILLET

Hi,

So 2.5.0-alpha will be RTC.
Good for me, it is what I personally prefer.

Will it be a fork of latest 2.4.x and trunk things will have to be
proposed, voted and backported?
Or will it be a fork from trunk with things likely never (IMHO) really
reviewed?

My own opinion is a copy of 2.4.x + RTC process because I think it is
safer. But I'm not sure it is what others have in mind.

CJ


Le 04/11/2017 à 11:59, Graham Leggett a écrit :
On 04 Nov 2017, at 12:03 PM, Steffen > wrote:



Soon we have:

branches 2.4.x
trunk
2.5.0-alpha
patches/2.4.x
patches/trunk

Please a procedure: *where*and*when*do we apply patches/fixes.


When: When you feel your change is appropriate, and when on 
review-then-commit branches you have received three +1’s including 
yours binding vote.


Where: Read on.

Everything starts on bleeding edge trunk, always, just as we always 
have done.


People propose backports to the older branches, in order, if people 
feel those patches are warranted, just as we always have done.


If a branch is commit-then-review (CTR), and you believe it is 
appropriate to do so, you commit to that branch, and if people have a 
problem with it, they will say so.


If a branch is review-then-commit (RTC), and you believe it is 
appropriate to do so, you propose a backport in STATUS and when you 
get three +1’s (including your own binding one), you commit to that 
branch.


The changes cascade down the branches as far as you feel is appropriate.

Concrete example.

You have a change. You believe this change should be backported to 
v2.4.x, so that people using the current v2.4.x line will see your 
change. You commit it to trunk. You propose it for backport to 
v2.5.0-alpha. You propose it for backport to v2.4.x. You could carry 
on down to v2.2.x if you believe it is warranted, but you probably 
won’t believe it is warranted for a branch that is end of life.


What do we want?

- All changes on v2.2.x should also appear in all higher branches and 
trunk.
- All changes on v2.4.x should also appear in all higher branches and 
trunk.

- All changes on v2.5.x should also appear in trunk.

What _don’t_ we want?

- Changes to appear on v2.4.x that _aren’t_ also made to v2.5.x. For 
obvious reasons we don’t want things in v2.4.x to suddenly vanish from 
v2.5/v2.6; except for
- Code that only appears in older branches. For example if a module is 
removed, you physically can’t patch it in trunk because it no longer 
exists. In these rare cases you would propose a fix for an older 
branch only. The rule here is “be sensible”.


Nothing has changed in our process.

Regards,
Graham
—





Re: svn commit: r1813027 - /httpd/httpd/branches/2.4.x/STATUS

2017-11-01 Thread Marion &amp; Christophe JAILLET

Same analysis here. The 2 declarations are the same.

CJ


Le 01/11/2017 à 11:02, Rainer Jung a écrit :

Hi Bill,

Am 31.10.2017 um 21:29 schrieb William A Rowe Jr:

On Mon, Oct 23, 2017 at 10:17 AM,  wrote:

Author: ylavic
Date: Mon Oct 23 15:17:02 2017
New Revision: 1813027

URL: http://svn.apache.org/viewvc?rev=1813027=rev
Log:
Update comment according to patch version (v5).

Modified:
 httpd/httpd/branches/2.4.x/STATUS

@@ -138,7 +137,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
   +1: ylavic,
    wrowe: Suspect that this is an MMN Major bump, not minor 
without some
   additional detection/workaround of legacy 2.4 
compiled modules.
- ylavic: Changed to v4 (+r1812193) which hopefully should 
address compat
+ ylavic: Changed to v5 (+r1812193) which hopefully should 
address compat

   issues, Bill?


That seems to help with the config parser.

This looks problematic; it is undoubtedly a binary ABI change to a
public interface.

-APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, scheme_handler, 
(request_rec *r,

-  proxy_worker *worker, proxy_server_conf
*conf, char *url,
-  const char *proxyhost, apr_port_t proxyport))
-APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, canon_handler, 
(request_rec *r,

-  char *url))
[...]
+APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, scheme_handler,
+  (request_rec *r, proxy_worker *worker,
+   proxy_server_conf *conf, char *url,
+   const char *proxyhost, apr_port_t 
proxyport))

+APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, canon_handler,
+  (request_rec *r, char *url))



This part you cited to me looks like just a reformat (position of line 
breaks changed), but I couldn't spot a functional change there.


Regards,

Rainer





Re: Pruning working branches (Was: Re: Why?)

2017-10-25 Thread Marion &amp; Christophe JAILLET

+1


Le 24/10/2017 à 23:05, William A Rowe Jr a écrit :

On Tue, Oct 24, 2017 at 8:11 AM, William A Rowe Jr  wrote:

On Tue, Oct 24, 2017 at 3:28 AM, Steffen  wrote:

On Tuesday 24/10/2017 at 10:26, Steffen wrote:

Can someone clean up the not needed anymore  backports/branches
  http://svn.apache.org/viewvc/httpd/httpd/branches/


httpd 2.4.1 was tagged at r1243503.

I'd propose we start by pruning all working branches not updated since this tag.

Thoughts?

To clarify; this list consists of;

Last rev – Last modified – Branch

  371484  11 years  async-read-dev/
  367678  11 years  authz-dev/
  446636  11 years  cache-refactor/
  369019  11 years  execd-dev/
  393955  11 years  fcgi-proxy-dev/
  8095458 years  httpd-2.2-proxy/
  431328  11 years  httpd-proxy-scoreboard/
  1200612  5 years  input-filter-dev/
  171035  12 years  listen-protocol/
  151147  12 years  proxy-reqbody/
  1150173  6 years  revert-ap-ldap/
  7236558 years  wombat-integration/





Re: svn commit: r1787104 - /httpd/httpd/branches/2.4.x/STATUS

2017-03-21 Thread Marion &amp; Christophe JAILLET

Hi,

+static const char *cmd_servertype(cmd_parms *cmd, void *in_dconf,

+   const char *val)
+{
+[...]

+else if (!strcasecmp(val, "FPM") || !strcasecmp(val, "PHP-FPM")) {

Why?

PHP-FPM is not documented, neither in the doc, nor in AP_INIT_TAKE1.



In this function, ap_cstr_casecmp could alos be used for consistancy reason.

Just my 2 cents,
CJ



Le 15/03/2017 à 23:30, cove...@apache.org a écrit :

Author: covener
Date: Wed Mar 15 22:30:23 2017
New Revision: 1787104

URL: http://svn.apache.org/viewvc?rev=1787104=rev
Log:
vote


Modified:
 httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1787104=1787103=1787104=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Wed Mar 15 22:30:23 2017
@@ -140,7 +140,7 @@ RELEASE SHOWSTOPPERS:
http://svn.apache.org/r1782482
http://svn.apache.org/r1782532
   2.4.x patch: http://home.apache.org/~jim/patches/mod_proxy_fcgi-v3.patch
- +1: jim
+ +1: jim, covener
  
  PATCHES ACCEPTED TO BACKPORT FROM TRUNK:

[ start all new proposals below, under PATCHES PROPOSED. ]







Re: server-status script donated to ASF

2017-03-20 Thread Marion &amp; Christophe JAILLET

Hi,

when running, the page get longer 5 seconds or so.

In the JS code, there is:

// resize pane
document.getElementById('leftpane').style.height = 
document.getElementById('wrapper').getBoundingClientRect().height + "px";


I guess that is "growing page" is coming from there.

What it is used for?

CJ

Le 20/03/2017 à 14:01, Daniel Gruno a écrit :

On 03/20/2017 02:01 PM, Jim Jagielski wrote:

Since these are docs, does that mean they can be
CTR'ed into 2.4? :)

probably? :) it's just an example script, nothing that needs compiling
or counts as de facto replacement yet :)


On Mar 20, 2017, at 8:57 AM, Daniel Gruno  wrote:

On 03/20/2017 01:56 PM, Jim Jagielski wrote:

Cool... URL?

https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/server-status/


On Mar 15, 2017, at 10:23 AM, Daniel Gruno  wrote:

FWIW, the stuff that powers https://httpd.apache.org/server-status has
now been donated to the HTTPd project.

With regards,
Daniel.






Re: svn commit: r1787525 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_autoindex.xml modules/generators/mod_autoindex.c

2017-03-18 Thread Marion &amp; Christophe JAILLET



Le 18/03/2017 à 03:51, cove...@apache.org a écrit :

Author: covener
Date: Sat Mar 18 02:51:02 2017
New Revision: 1787525

URL: http://svn.apache.org/viewvc?rev=1787525=rev
Log:
Add IndexOptions UseOldDateFormat

   *) mod_autoindex: Add IndexOptions UseOldDateFormat to allow the date
  format from 2.2 in the Last Modified column. PR60846.
   
PR34014 / r903052 changed date format for autoindex


[...]

@@ -1844,8 +1851,9 @@ static void output_directories(struct en
  apr_time_exp_t ts;
  apr_time_exp_lt(, ar[x]->lm);
  apr_strftime(time_str, , sizeof(time_str),
-"%Y-%m-%d %H:%M  ", );
-ap_rputs(time_str, r);
+datetime_format,
+);
+ap_rvputs(r, time_str, "  ", NULL);
  }
  else {
  /*Length="1975-04-07 01:23  " (see 4 lines above) */


The lines below have been changed this way in r903052:

-/*Length="22-Feb-1998 23:42  " (see 4 lines above) */
+/*Length="1975-04-07 01:23  " (see 4 lines above) */
 ap_rputs("   ", r);


So I think that there is a small display artifact and that there is 1 
extra space when the "%Y-%m-%d %H:%M" format is used.


I've not tested, so I don't know if it makes a real difference.

Also the comment should be changed in something like /* 
Length="22-Feb-1998 23:42  " or Length="1975-04-07 01:23  ". See 
'datetime_format' definition */


CJ


Re: svn commit: r1783413 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/mpm/event/event.c

2017-02-17 Thread Marion &amp; Christophe JAILLET

No CHANGES entry?

CJ


Le 17/02/2017 à 16:36, j...@apache.org a écrit :

Author: jim
Date: Fri Feb 17 15:36:02 2017
New Revision: 1783413

URL: http://svn.apache.org/viewvc?rev=1783413=rev
Log:
Merge r1774541 from trunk:

event: close a race condition where we might re-enable listeners while they
are already or about to be closed.


Submitted by: ylavic
Reviewed by: ylavic, jim, wrowe

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/server/mpm/event/event.c


Re: JSON for mod_status

2017-01-21 Thread Marion &amp; Christophe JAILLET

++1

:)


Author: jailletc36
Date: Fri Jan  6 07:19:20 2017
New Revision: 1777535

URL:http://svn.apache.org/viewvc?rev=1777535=rev
Log:
update

Modified:
httpd/httpd/trunk/STATUS

Modified: httpd/httpd/trunk/STATUS
URL:http://svn.apache.org/viewvc/httpd/httpd/trunk/STATUS?rev=1777535=1777534=1777535=diff
==
--- httpd/httpd/trunk/STATUS (original)
+++ httpd/httpd/trunk/STATUS Fri Jan  6 07:19:20 2017
@@ -140,6 +140,14 @@ THINGS THAT SHOULD BE CONSIDERED EARLY I
   * REST-based administration for existing (balancer/etc) and new dynamic
 runtime changes (see above)
 
+  * Improve the look of generated pages (status, load-balancer...) with dynamic

+update of the values. Generate HTML5 pages, instead of 3.2, Get rid of 
XHTML
+in the generated pages.
+
+  * Add performance monitoring of the server, of each module (?), in order to 
help
+understanding what worth looking at in order to improve overall 
performance.
+
(https://cdn.wp.nginx.com/wp-content/uploads/2016/12/Amplify-Dashboards-page-base-for-filters.png)
+
 OLD ISSUES THAT WERE THOUGHT TO BE SHOWSTOPPERS FOR 2.4 BUT OBVIOUSLY WEREN'T:
 
   * Handling of non-trailing / config by non-default handler is broken




Le 18/01/2017 à 10:56, Daniel Gruno a écrit :

On 01/17/2017 07:33 PM, Jim Jagielski wrote:

It all depends on what Bill decides regarding mod_bmx and if
it is something we intent to backport to 2.4.x

Still not sure on how to *use* BMX, or how other modules
"hook in" (right now we have several modules hook into
mod_status so the "how" is well known and documented), so
I would require some sort of docs in addition to the actual
code, of course.

Some JFDI in the meantime; https://httpd.apache.org/server-status :)
JSON: http://httpd.apache.org/server-status?view=json_status

With regards,
Daniel.


On Jan 17, 2017, at 12:35 PM, Luca Toscano  wrote:



2016-11-30 18:54 GMT+01:00 Jim Jagielski :
I'm thinking about adding JSON support to mod_status...
the "plain" version output really stinks and lacks parity
w/ the info we provide via HTML, and it would be nice
to produce a really easily parseable format.

Thoughts...?

I know it was extensively discussed, but do we have an agreement about a plan 
to add this feature?  :)

Luca









Re: [VOTE] Release Apache httpd 2.4.25 as GA

2016-12-17 Thread Marion &amp; Christophe JAILLET

Proposed fix in r1774728.

A solution, stating that the tests have been skipped because of sed 
location, would be better, though.


CJ

Le 16/12/2016 à 21:46, Jacob Champion a écrit :

On 12/16/2016 12:44 PM, William A Rowe Jr wrote:

I expect this is a bug in the 2.4.x branch. However, I found the same
exceptions in 2.4.23 tag, so this is not a regression, and Joe is still
researching what is happening here, so it doesn't seem to be something
we would want to hold up a release for.


Yeah, in my case I think it's just that the tests don't exit after 
skipping (i.e. 48 out of 24 tests are run...). Not a showstopper.


--Jacob





Re: svn commit: r1769900 - /httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en

2016-11-15 Thread Marion &amp; Christophe JAILLET

Hi,

why removing compatibility note (i.e. 2.4.7) ?

CJ


Le 15/11/2016 à 23:57, elu...@apache.org a écrit :

Author: elukey
Date: Tue Nov 15 22:57:36 2016
New Revision: 1769900

URL: http://svn.apache.org/viewvc?rev=1769900=rev
Log:
documentation rebuild

Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en

Modified: httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en?rev=1769900=1769899=1769900=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en Tue Nov 15 22:57:36 
2016
@@ -309,8 +309,16 @@ available in 2.4.10 and later
  
  setifempty

  The request header is set, but only if there is no previous header
-with this name.
-Available in 2.4.7 and later.
+with this name.
+
+The Content-Type header is a special use case since there might be
+the chance that its value have been determined but the header is not part
+of the response when setifempty is evaluated.
+It is safer to use set for this use case like in the
+following example:
+Header set Content-Type "text/plain" "expr=-z 
%{CONTENT_TYPE}"
+
+
  
  unset

  The response header of this name is removed, if it exists.







Re: svn commit: r1756560 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS include/ap_mmn.h modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h

2016-08-16 Thread Marion &amp; Christophe JAILLET

Hi,


Le 17/08/2016 à 01:17, yla...@apache.org a écrit :

Author: ylavic
Date: Tue Aug 16 23:17:46 2016
New Revision: 1756560

URL: http://svn.apache.org/viewvc?rev=1756560=rev
Log:
Merge r1746207 from trunk:

mod_dav: Add support for childtags to dav_error.

Submitted by: minfrin
Reviewed by: minfrin, jim, ylavic

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/include/ap_mmn.h
 httpd/httpd/branches/2.4.x/modules/dav/main/mod_dav.c
 httpd/httpd/branches/2.4.x/modules/dav/main/mod_dav.h

[...]

Modified: httpd/httpd/branches/2.4.x/modules/dav/main/mod_dav.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/dav/main/mod_dav.c?rev=1756560=1756559=1756560=diff
==
--- httpd/httpd/branches/2.4.x/modules/dav/main/mod_dav.c (original)
+++ httpd/httpd/branches/2.4.x/modules/dav/main/mod_dav.c Tue Aug 16 23:17:46 
2016
@@ -364,16 +364,33 @@ static int dav_error_response_tag(reques
  ap_rputs(" xmlns:m=\"http://apache.org/dav/xmlns\";, r);
  }
  
-if (err->namespace != NULL) {

-ap_rprintf(r,
-   " xmlns:C=\"%s\">" DEBUG_CR
-   "" DEBUG_CR,
-   err->namespace, err->tagname);
+if (err->childtags) {
+if (err->namespace != NULL) {
+ap_rprintf(r,
+" xmlns:C=\"%s\">" DEBUG_CR
+"%s" DEBUG_CR,
+err->namespace,
+err->tagname, err->childtags, err->tagname);
+}
+else {
+ap_rprintf(r,
+">" DEBUG_CR
+"%s" DEBUG_CR,

Shouldn't this be:
"%s" DEBUG_CR,
in order to close the D tag?


+err->tagname, err->childtags, err->tagname);
+}
  }
  else {
-ap_rprintf(r,
-   ">" DEBUG_CR
-   "" DEBUG_CR, err->tagname);
+if (err->namespace != NULL) {
+ap_rprintf(r,
+" xmlns:C=\"%s\">" DEBUG_CR
+"" DEBUG_CR,
+err->namespace, err->tagname);
+}
+else {
+ap_rprintf(r,
+">" DEBUG_CR
+"" DEBUG_CR, err->tagname);
+}
  }
  
  /* here's our mod_dav specific tag: */

[...

CJ

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus



Re: T 2.4.23 tomorrow (Thurs) ??

2016-06-23 Thread Marion &amp; Christophe JAILLET
Well, perl seems to be at the expected place but perlsub.pod seems to be 
nowhere.


Must be an issue on my test environment or a file not included in my 
distro or a change between perl 5.18 and 5.22


Thx for your time and explanation.

CJ


Le 23/06/2016 à 10:55, Stefan Eissing a écrit :

As you can see: in your installation, the /getfiles-perl-pod/perlsub.pod cannot 
be found.
In t/conf/httpd.conf:Alias /getfiles-binary-perl /usr/bin/perl

So, maybe you do have perl in a different location?





Re: T 2.4.23 tomorrow (Thurs) ??

2016-06-23 Thread Marion &amp; Christophe JAILLET

Current 2.4.x, Ubuntu 16.04:

The output with -verbose is:

t/filter/case.t ..
1..4
# Running under perl version 5.022001 for linux
# Current time local: Thu Jun 23 10:39:03 2016
# Current time GMT:   Thu Jun 23 08:39:03 2016
# Using Test.pm version 1.26
# Using Apache/Test.pm version 1.40
ok 1
# testing mod_alias with /getfiles-perl-pod/perlsub.pod
# expected 200
# received 404
not ok 2
# Failed test 2 in t/filter/case.t at line 39 fail #2
# testing mod_cgi with /modules/cgi/perl.pl
# expected 200
# received 200
ok 3
# testing mod_test_rwrite with /test_rwrite
# expected 200
# received 200
ok 4
Failed 1/4 subtests

Test Summary Report
---
t/filter/case.t (Wstat: 0 Tests: 4 Failed: 1)
  Failed test:  2
Files=1, Tests=4,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.29 cusr  
0.06 csys =  0.37 CPU)

Result: FAIL
Failed 1/1 test programs. 1/4 subtests failed.


I have 4 tests, you have 3.
Could you re-run with -verbose to see which one is not run on your system?

CJ



Le 23/06/2016 à 10:22, Stefan Eissing a écrit :

Current 2.4.x, OS X:

t/filter/case.t .. ok
All tests successful.
Files=1, Tests=3,  1 wallclock secs ( 0.01 usr  0.00 sys +  0.36 cusr  0.18 
csys =  0.55 CPU)
Result: PASS


Am 23.06.2016 um 10:08 schrieb Marion & Christophe JAILLET 
<christophe.jail...@wanadoo.fr>:



Le 22/06/2016 à 22:05, Jim Jagielski a écrit :

Subj sez it all... afaict, there are no showstoppers and
no outstanding issues (none seen in STATUS, or noted as
such on any Email threads).

So... anyone opposed to a T tomorrow in the hopes
of getting this out to people by the start of next week??


Hi,

while testing, I have:

t/filter/case.t ..
1..4
# Running under perl version 5.022001 for linux
# Current time local: Thu Jun 23 09:45:04 2016
# Current time GMT:   Thu Jun 23 07:45:04 2016
# Using Test.pm version 1.26
# Using Apache/Test.pm version 1.40
ok 1
# testing mod_alias with /getfiles-perl-pod/perlsub.pod
# expected 200
# received 404
not ok 2


I don't know how to diagnose it.

CJ






Re: T 2.4.23 tomorrow (Thurs) ??

2016-06-23 Thread Marion &amp; Christophe JAILLET



Le 22/06/2016 à 22:05, Jim Jagielski a écrit :

Subj sez it all... afaict, there are no showstoppers and
no outstanding issues (none seen in STATUS, or noted as
such on any Email threads).

So... anyone opposed to a T tomorrow in the hopes
of getting this out to people by the start of next week??



Hi,

while testing, I have:

t/filter/case.t ..
1..4
# Running under perl version 5.022001 for linux
# Current time local: Thu Jun 23 09:45:04 2016
# Current time GMT:   Thu Jun 23 07:45:04 2016
# Using Test.pm version 1.26
# Using Apache/Test.pm version 1.40
ok 1
# testing mod_alias with /getfiles-perl-pod/perlsub.pod
# expected 200
# received 404
not ok 2


I don't know how to diagnose it.

CJ


Re: svn commit: r1747056 - in /httpd/httpd/branches/2.4.x: ./ STATUS modules/mappers/mod_rewrite.c

2016-06-07 Thread Marion &amp; Christophe JAILLET



Le 07/06/2016 à 06:59, William A Rowe Jr a écrit :
On Mon, Jun 6, 2016 at 3:10 PM, Marion & Christophe JAILLET 
<christophe.jail...@wanadoo.fr <mailto:christophe.jail...@wanadoo.fr>> 
wrote:


ap_casecmpstr breaks 2.4.x build.
Keep strncasecmp for now? (waiting for ap_cstr_casecmp[n])

Le 06/06/2016 à 21:11, j...@apache.org <mailto:j...@apache.org> a
écrit :

Author: jim
Date: Mon Jun  6 19:11:20 2016
New Revision: 1747056

URL: http://svn.apache.org/viewvc?rev=1747056=rev
Log:
Merge r1744206 from trunk:

mod_rewrite: adding h2:// and h2c:// proxy schemes to absolute
uri detection, patch by Evgeny Kotkov
Submitted by: icing
Reviewed/backported by: jim

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/modules/mappers/mod_rewrite.c


Modified: httpd/httpd/branches/2.4.x/STATUS
URL:

http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1747056=1747055=1747056=diff

==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Mon Jun  6 19:11:20 2016
@@ -115,12 +115,6 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
- *) mod_rewrite: support new h2:// and h2c:// proxy url
schemes in detection
- of absolute urls:
- trunk patch: http://svn.apache.org/r1744206
- 2.4.x patch: trunk works
- +1: icing, jim, covener


Well, contrary to the commit message that failed to credit to the two 
other
reviewers, it did have 3 +1's... we are pretty specific on backport 
policy.


Is that a vote against, jallettc? If not, the backport remains valid.



No, it's not a vote against.
It is just a remark that we should move forward and either backport 
ap_cstr_casecmp[n] or decide to delay it to another release.


We are building 2.4.21, so breaking compilation for a few days is, IMHO, 
acceptable.



I will have limited time until end of the week to update my 
ap_cstr_casecmp[n] backport proposal.

So if anyone wants to update it before, do not hesitate.

CJ


Re: svn commit: r1747056 - in /httpd/httpd/branches/2.4.x: ./ STATUS modules/mappers/mod_rewrite.c

2016-06-06 Thread Marion &amp; Christophe JAILLET

ap_casecmpstr breaks 2.4.x build.
Keep strncasecmp for now? (waiting for ap_cstr_casecmp[n])

CJ


Le 06/06/2016 à 21:11, j...@apache.org a écrit :

Author: jim
Date: Mon Jun  6 19:11:20 2016
New Revision: 1747056

URL: http://svn.apache.org/viewvc?rev=1747056=rev
Log:
Merge r1744206 from trunk:

mod_rewrite: adding h2:// and h2c:// proxy schemes to absolute uri detection, 
patch by Evgeny Kotkov
Submitted by: icing
Reviewed/backported by: jim

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/modules/mappers/mod_rewrite.c


Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1747056=1747055=1747056=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Mon Jun  6 19:11:20 2016
@@ -115,12 +115,6 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
  
  
- *) mod_rewrite: support new h2:// and h2c:// proxy url schemes in detection

- of absolute urls:
- trunk patch: http://svn.apache.org/r1744206
- 2.4.x patch: trunk works
- +1: icing, jim, covener
-
*) Correct the behavior and interaction between SSLProxyCheckPeer[CN|Name],
   such that disabling either disables both, and that enabling either will
   trigger the more comprehensive SSLProxyCheckPeerName behavior.

Modified: httpd/httpd/branches/2.4.x/modules/mappers/mod_rewrite.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/mappers/mod_rewrite.c?rev=1747056=1747055=1747056=diff
==
--- httpd/httpd/branches/2.4.x/modules/mappers/mod_rewrite.c (original)
+++ httpd/httpd/branches/2.4.x/modules/mappers/mod_rewrite.c Mon Jun  6 
19:11:20 2016
@@ -560,6 +560,14 @@ static unsigned is_absolute_uri(char *ur
  *sqs = 1;
  return 8;
  }
+else if (!ap_casecmpstrn(uri, "2://", 4)) {/* h2:// */
+*sqs = 1;
+return 5;
+}
+else if (!ap_casecmpstrn(uri, "2c://", 5)) {   /* h2c://*/
+*sqs = 1;
+return 6;
+}
  break;
  
  case 'l':








Re: svn commit: r1743577 [1/2] - in /httpd/httpd/branches/2.4.x: docs/manual/mod/mod_proxy_http2.xml modules/http2/NWGNUproxyht2 modules/http2/h2_proxy_session.c modules/http2/h2_proxy_session.h modul

2016-05-12 Thread Marion &amp; Christophe JAILLET

Hi,

there are 2 valid issues spotted by smatch in debug logging message:

modules/http2/h2_proxy_session.c:339 on_data_chunk_recv() error: we 
previously assumed 'stream' could be null (see line 338)
modules/http2/h2_proxy_session.c:425 stream_data_read() error: we 
previously assumed 'stream' could be null (see line 424)


I'll also give a closer look at it tonight if no one fix it in the meantime.

CJ

Le 12/05/2016 à 23:31, j...@apache.org a écrit :

Author: jim
Date: Thu May 12 21:31:44 2016
New Revision: 1743577

URL: http://svn.apache.org/viewvc?rev=1743577=rev
Log:
Merge r1729208, r1735668, r1735668, r1735931, r1735935, r1735942 from trunk:

let proxy handler forward ALPN protocol strings for ssl proxy connections

Remove leftover comment

Remove leftover comment

APLOGNO update for mod_proxy_http2

fix APLOGNO at wrong place, me stupid

h2_proxy_session: fill in missing APLOGNO()s.
Submitted by: icing, jailletc36, jailletc36, icing, icing, ylavic
Reviewed/backported by: jim

Added:
 httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.xml
 httpd/httpd/branches/2.4.x/modules/http2/NWGNUproxyht2
 httpd/httpd/branches/2.4.x/modules/http2/h2_proxy_session.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_proxy_session.h
 httpd/httpd/branches/2.4.x/modules/http2/mod_proxy_http2.c
 httpd/httpd/branches/2.4.x/modules/http2/mod_proxy_http2.h





Re: svn commit: r1743577 [1/2] - in /httpd/httpd/branches/2.4.x: docs/manual/mod/mod_proxy_http2.xml modules/http2/NWGNUproxyht2 modules/http2/h2_proxy_session.c modules/http2/h2_proxy_session.h modul

2016-05-12 Thread Marion &amp; Christophe JAILLET

Hi all,

mod_proxy_http2 does not compile because of changes made in mod_hhtp2:

   - h2_ihash_is_empty vs h2_ihash_empty
   - h2_request_create vs h2_req_create
   - modified header files
   - ...

If not fixed in the mean time, I'll give a look at it tonight.


Do we need to go thru the formal voting process for fixing build failure 
on an experimental module?


CJ


Le 12/05/2016 à 23:31, j...@apache.org a écrit :

Author: jim
Date: Thu May 12 21:31:44 2016
New Revision: 1743577

URL: http://svn.apache.org/viewvc?rev=1743577=rev
Log:
Merge r1729208, r1735668, r1735668, r1735931, r1735935, r1735942 from trunk:

let proxy handler forward ALPN protocol strings for ssl proxy connections

Remove leftover comment

Remove leftover comment

APLOGNO update for mod_proxy_http2

fix APLOGNO at wrong place, me stupid

h2_proxy_session: fill in missing APLOGNO()s.
Submitted by: icing, jailletc36, jailletc36, icing, icing, ylavic
Reviewed/backported by: jim

Added:
 httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.xml
 httpd/httpd/branches/2.4.x/modules/http2/NWGNUproxyht2
 httpd/httpd/branches/2.4.x/modules/http2/h2_proxy_session.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_proxy_session.h
 httpd/httpd/branches/2.4.x/modules/http2/mod_proxy_http2.c
 httpd/httpd/branches/2.4.x/modules/http2/mod_proxy_http2.h






Re: svn commit: r1736683 - /httpd/httpd/trunk/docs/manual/mod/mod_authnz_ldap.xml

2016-03-26 Thread Marion &amp; Christophe JAILLET
As far as I've seen, directive names used within the corresponding 
 bloc do not have a link to themselves.

That's why I have removed some in this commit.

In the same commit, I've also added some missing module= for some other 
directives in order to keep the link to them.


As an example, in this commit, you can find:

+AuthLDAPSubGroupAttribute directive identifies the
+labels of group members and the AuthLDAPGroupAttribute

No module= for AuthLDAPSubGroupAttribute but one for 
AuthLDAPGroupAttribute, because we are in the AuthLDAPSubGroupAttribute 
 bloc.



I've never seen this "rule" written anywhere, but it looks a quite 
classical way to do within the online doc.
I personally find it logical and it helps, IMHO, to quickly see if the 
explanation we are reading it about the current directive or if it is 
related to something else, which can be found somewhere else.


If module= everywhere is the preferred way, that's good for me and will 
update accordingly.



BTW, I will backport port these changes during the WE but I'm in the 
process to synch 2.4 and trunk for this given file. Started but not 
finished yet.


CJ



Le 26/03/2016 13:51, Eric Covener a écrit :

On Sat, Mar 26, 2016 at 3:51 AM,   wrote:

-module="mod_authnz_ldap">AuthLDAPBindPassword if you
+>AuthLDAPBindPassword if you
  absolutely need them to search the directory.


I am in the habit of always adding module= so we get the directive as
a hyperlink.  Is there a rationale for removing them?





Re: svn commit: r1735610 - in /httpd/httpd/branches/2.4.x: ./ modules/http2/

2016-03-19 Thread Marion &amp; Christophe JAILLET



Le 18/03/2016 15:48, ic...@apache.org a écrit :

Author: icing
Date: Fri Mar 18 14:48:36 2016
New Revision: 1735610

URL: http://svn.apache.org/viewvc?rev=1735610=rev
Log:
Merge of 1735608,1735609 from trunk:

mod_http2: stream cleanup on GOAWAY handling, PUSHes prohibited after client 
GOAWAY.


Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/modules/http2/h2.h
 httpd/httpd/branches/2.4.x/modules/http2/h2_conn_io.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_filter.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_mplx.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_mplx.h
 httpd/httpd/branches/2.4.x/modules/http2/h2_session.c
 httpd/httpd/branches/2.4.x/modules/http2/h2_session.h
 httpd/httpd/branches/2.4.x/modules/http2/h2_version.h


Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1735610=1735609=1735610=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Fri Mar 18 14:48:36 2016
@@ -1,10 +1,7 @@
   -*- coding: utf-8 -*-
  
-Changes with Apache 2.4.19

-
-  *) mod_http2: slave connections are reused for several requests, improved
- performance and better memory use. [Stefan Eissing]
-

Is this removal intentional?

CJ


+  *) mod_http2: disabling PUSH when client sends GOAWAY.
+
*) mod_rewrite: Don't implicitly URL-escape the original query string
   when no substitution has changed it (like PR50447 but server context)
   [Evgeny Kotkov ]


Re: svn commit: r1729495 [2/2] - in /httpd/httpd/branches/2.4.x: ./ modules/aaa/ modules/arch/win32/ modules/core/ modules/examples/ modules/filters/ modules/http2/ modules/loggers/ modules/lua/ modul

2016-02-22 Thread Marion &amp; Christophe JAILLET



Le 22/02/2016 22:21, Rainer Jung a écrit :

Am 15.02.2016 um 07:28 schrieb Christophe JAILLET:

Le 10/02/2016 00:09, rj...@apache.org a écrit :

Modified: httpd/httpd/branches/2.4.x/server/mpm/event/event.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/mpm/event/event.c?rev=1729495=1729494=1729495=diff 



@@ -3245,7 +3247,7 @@ static int event_check_config(apr_pool_t
  ap_log_error(APLOG_MARK, APLOG_WARNING | APLOG_STARTUP,
0, NULL, APLOGNO(00497)
   "WARNING: ServerLimit of %d exceeds
compile-time "
   "limit of", server_limit);
-ap_log_error(APLOG_MARK, APLOG_WARNING | APLOG_STARTUP,
0, NULL,
+ap_log_error(APLOG_MARK, APLOG_WARNING | APLOG_STARTUP,
0, NULL, APLOGNO(03105)
   " %d servers, decreasing to %d.",
   MAX_SERVER_LIMIT, MAX_SERVER_LIMIT);
  } else {



Should we really add an APLOGNO here? It looks like a multi-line log
message.

This is the same for APLOGNO(03105) --> APLOGNO(03116) in event.c.
Similar code can also be found in other MPM.


You are right. I wonder whether we actually want to reformat those 
startup messages to single (long) line messages. What do you (and 
others) think?


Regards,

Rainer


+1, it is what I had in mind to clarify and avoid false positive when 
using coccinelle.


CJ


Re: [PATCH] Reduce memory footprint in mod_dav's property code

2015-12-21 Thread Marion &amp; Christophe JAILLET
You can also have a look at 
https://bz.apache.org/bugzilla/show_bug.cgi?id=48130


Le 22/12/2015 01:13, Stefan Fuhrmann a écrit :

Hi,

I stumbled over this while investigation an OOM report from a
Subversion user [1].  Due to unfortunate circumstances [2], I've
seen directory listings with a few 1 entries eat 10s of GB
of RAM.  Those circumstances are being addressed but the root
cause is in mod_dav and the patch below fixes it.

The problem is that dav_open_propdb creates a pool that
dav_close_propdb can't destroy.  So, for every property, at least
8 KB of memory will be allocated.  If we simply use the parent
pool as is, only a few 100 bytes will be used.

Moreover, if the APR allocator should return a larger block once
in a while, that block will get used up nicely before more memory
is allocated.  So with this patch, the worst case will still use
only about to 1/10th of the current best case for large collections.

-- Stefan^2.

[1] 
http://mail-archives.apache.org/mod_mbox/subversion-users/201512.mbox/%3C1CEE115D02633942A40D49D447DCF46E432F3A32%40SD01CFMM0202.OMEGA.DCE-EIR.NET%3E
[2] 
http://mail-archives.apache.org/mod_mbox/subversion-dev/201512.mbox/%3C5676A54F.9040609%40apache.org%3E



[[[
Fix a pool handling asymmetry in mod_dav that caused inefficient
memory usage with collection properties.

If we can't clear nor destroy the local pool in dav_propdb, there
is no point in creating it as a sub-pool of its parent.

* modules/dav/main/props.c
  (DAV_PROPDB_LOCAL_POOL): New compile-time switch replacing the
   plain "#if 0" in dav_close_propdb.  It
   ensures consistent behaviour between
   open and close in the future.
  (dav_open_propdb): If we can't clear the pool, we may as well use
 its parent directly.
  (dav_close_propdb): Use the new define.
]]]

[[[
Index: modules/dav/main/props.c
===
--- modules/dav/main/props.c(revision 1721073)
+++ modules/dav/main/props.c(working copy)
@@ -167,6 +167,16 @@

 #define DAV_EMPTY_VALUE"\0"/* TWO null terms */

+/*
+** Currently, mod_dav's pool usage doesn't allow clearing the pool
+** at dav_propdb.p . Therefore, we won't create a sub-pool for it
+** and use the request's pool directly instead.
+**
+** Once the pool usage issue has been fixed, set this to 1 for optimal
+** memory usage.
+*/
+#define DAV_PROPDB_LOCAL_POOL  0
+
 struct dav_propdb {
 apr_pool_t *p;/* the pool we should use */
 request_rec *r;   /* the request record */
@@ -537,7 +547,11 @@
 #endif

 propdb->r = r;
+#if DAV_PROPDB_LOCAL_POOL
 apr_pool_create(>p, r->pool);
+#else
+propdb->p = r->pool;
+#endif
 propdb->resource = resource;
 propdb->ns_xlate = ns_xlate;

@@ -562,8 +576,7 @@
 (*propdb->db_hooks->close)(propdb->db);
 }

-/* Currently, mod_dav's pool usage doesn't allow clearing this 
pool. */

-#if 0
+#if DAV_PROPDB_LOCAL_POOL
 apr_pool_destroy(propdb->p);
 #endif
 }
]]]





Re: svn commit: r1717123 - /httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml

2015-12-02 Thread Marion &amp; Christophe JAILLET

Will fix.
Sorry for not seeing it myself.

CJ

Le 02/12/2015 15:28, Mike Rumph a écrit :

Comment below.

On 11/29/2015 1:00 PM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Sun Nov 29 21:00:32 2015
New Revision: 1717123

URL: http://svn.apache.org/viewvc?rev=1717123=rev
Log:
Fix doc as spotted by mat in online doc

Modified:
 httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml

Modified: httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml?rev=1717123=1717122=1717123=diff
== 


--- httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_allowmethods.xml Sun Nov 29 
21:00:32 2015

@@ -39,7 +39,7 @@ in order for it to rebuild correctly.
  
-This module makes it easy to restrict what HTTP methods can
+This module makes it easy to restrict what HTTP methods can be
  used on an server. The most common configuration would be:

Should be "on a server".












Re: svn commit: r1715876 - in /httpd/httpd/trunk: modules/cache/ modules/filters/ modules/generators/ modules/http/ modules/http2/ modules/loggers/ modules/mappers/ modules/metadata/ modules/proxy/ mo

2015-11-23 Thread Marion &amp; Christophe JAILLET

Hi,

1 typo below.

Moreover, this kind of patch is a good candidate for backport as it 
introduces many small differences between 2.4 and trunk.

Without a backport, backporting future patches may become a nightmare.

I would find useful to split it into several pieces.
The first one should apply cleanly to 2.4.x to ease backport.
Other parts should be splitted in "as many piece as necessary" for 
potential future backport.


CJ


Le 23/11/2015 17:46, yla...@apache.org a écrit :

Author: ylavic
Date: Mon Nov 23 16:46:01 2015
New Revision: 1715876

URL: http://svn.apache.org/viewvc?rev=1715876=rev
Log:
Use new ap_casecmpstr[n]() functions where appropriate (not exhaustive).

Modified:

Modified: httpd/httpd/trunk/modules/cache/cache_util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/cache_util.c?rev=1715876=1715875=1715876=diff
==
--- httpd/httpd/trunk/modules/cache/cache_util.c (original)
+++ httpd/httpd/trunk/modules/cache/cache_util.c Mon Nov 23 16:46:01 2015

[...]

@@ -1066,59 +1045,46 @@ int ap_cache_control(request_rec *r, cac
  cc->max_stale = 1;
  cc->max_stale_value = -1;
  }
-break;
  }
-else if (!strncasecmp(token, "min-fresh", 9)) {
+else if (!ap_casecmpstrn(token, "min-fresh", 9)) {
  if (token[9] == '=') {
  cc->min_fresh = 1;
  cc->min_fresh_value = apr_atoi64(token + 10);
  }
-break;
Thanks for that. I was about to commit the same kind of patch (remove 
useless break).



-}
-else if (!strcasecmp(token, "must-revalidate")) {
-cc->must_revalidate = 1;
  }
  break;
  }
  case 'o':
  case 'O': {
-if (!strcasecmp(token, "only-if-cached")) {
+if (!ap_casecmpstr(token, "only-if-cached")) {
  cc->only_if_cached = 1;
  }
  break;
  }
-case 'p':
-case 'P': {
-/* handle most common quickest cases... */
-if (!strcmp(token, "private")) {
-cc->private = 1;
-}
-/* ...then try slowest cases */
-else if (!strcasecmp(token, "public")) {
+case 'p': {

case 'P' removed?

Best regards,
CJ



Re: strncasecmp

2015-11-23 Thread Marion &amp; Christophe JAILLET
I just made a small application which takes as command line parameters 
the number of iteration to run, which version of the algorithm to use, 
the 2 strings to compare and the length to compare (or 0 for the non 'n' 
versions)



Compiled using
gcc -O3 test.c

Tested using
linux:~/Code_Source$ time ./a.out 1 1 
xcxcxcxcxcxcxcxcxcxcwwaa 
xcxcxcxcxcxcxcxcxcxcwwaa 0

Optimized (nb=1, len=0)
res = 0

real0m4.193s
user0m4.192s
sys0m0.000s



linux:~/Code_Source$ time ./a.out 0 1 
xcxcxcxcxcxcxcxcxcxcwwaa 
xcxcxcxcxcxcxcxcxcxcwwaa 0

 (nb=1, len=0)
res = 0

real0m1.708s
user0m1.704s
sys0m0.000s




See atatchement.

CJ


Le 23/11/2015 21:33, Yann Ylavic a écrit :

Hi Christophe,

On Mon, Nov 23, 2015 at 9:12 PM, Christophe JAILLET
 wrote:

I tried to do some but the benefit of the optimized version is not that
clear, at least on my system:
gcc 5.2.1
Linux linux 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC 2015
x86_64 x86_64 x86_64 GNU/Linux

Unfortunately, gcc 5.2.1 (i.e. latest compilers' versions) are not
widely used...

Did you try a code like ap_proxy_port_of_scheme() with values which
are unknown schemes?
Or even worse cases, with similarly chained strcasecmp() looking for
eg. "httpx" in something like {"httpa", "httpb", "httpc", ...,
"httpw"}?

Regards,
Yann.



#include 
#include 
#include 

#include 

/*
 * Provide our own known-fast implementation of str[n]casecmp()
 * NOTE: ASCII only!
 */
static const unsigned char ucharmap[] = {
0x0,  0x1,  0x2,  0x3,  0x4,  0x5,  0x6,  0x7,
0x8,  0x9,  0xa,  0xb,  0xc,  0xd,  0xe,  0xf,
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27,
0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f,
0x40,  'a',  'b',  'c',  'd',  'e',  'f',  'g',
 'h',  'i',  'j',  'k',  'l',  'm',  'n',  'o',
 'p',  'q',  'r',  's',  't',  'u',  'v',  'w',
 'x',  'y',  'z', 0x5b, 0x5c, 0x5d, 0x5e, 0x5f,
0x60,  'a',  'b',  'c',  'd',  'e',  'f',  'g',
 'h',  'i',  'j',  'k',  'l',  'm',  'n',  'o',
 'p',  'q',  'r',  's',  't',  'u',  'v',  'w',
 'x',  'y',  'z', 0x7b, 0x7c, 0x7d, 0x7e, 0x7f,
0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f,
0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97,
0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f,
0xa0, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7,
0xa8, 0xa9, 0xaa, 0xab, 0xac, 0xad, 0xae, 0xaf,
0xb0, 0xb1, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 0xb7,
0xb8, 0xb9, 0xba, 0xbb, 0xbc, 0xbd, 0xbe, 0xbf,
0xc0, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7,
0xc8, 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf,
0xd0, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, 0xd7,
0xd8, 0xd9, 0xda, 0xdb, 0xdc, 0xdd, 0xde, 0xdf,
0xe0, 0xe1, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7,
0xe8, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef,
0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7,
0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff
};

int ap_strcasecmp(const char *s1, const char *s2)
{
const unsigned char *ps1 = (const unsigned char *) s1;
const unsigned char *ps2 = (const unsigned char *) s2;

while (ucharmap[*ps1] == ucharmap[*ps2++]) {
if (*ps1++ == '\0') {
return (0);
}
}
return (ucharmap[*ps1] - ucharmap[*--ps2]);
}

int ap_strncasecmp(const char *s1, const char *s2, int n)
{
const unsigned char *ps1 = (const unsigned char *) s1;
const unsigned char *ps2 = (const unsigned char *) s2;
while (n--) {
if (ucharmap[*ps1] != ucharmap[*ps2++]) {
return (ucharmap[*ps1] - ucharmap[*--ps2]);
}
if (*ps1++ == '\0') {
break;
}
}
return (0);
}

#define PROG argv[0]
#define METHOD argv[1]
#define NB argv[2]
#define S1 argv[3]
#define S2 argv[4]
#define LEN argv[5]

/* The ++ are here to try to prevent some optimization done by gcc */
#define FOR for (i=0; i  S1 S2 \n", PROG);
return 0;
}

len = atoi(LEN);
nb  = atoi(NB);

if (*METHOD == '0') {
printf(" (nb=%d, len=%d)\n", nb, len);
if (len == 0) {
FOR {
/* really use the result of the function */
res |= strcasecmp(S1, S2);
}
}
else {
FOR {
res |= strncasecmp(S1, S2, len);
}
}
}
else {
printf("Optimized (nb=%d, len=%d)\n", nb, len);
if (len == 0) {
FOR {

Re: svn commit: r1715294 - /httpd/httpd/trunk/server/core.c

2015-11-20 Thread Marion &amp; Christophe JAILLET

That was I first thought too.

When I looked at r1715255, I noticed:
 const char *conn = apr_table_get(r->headers_in, "Connection");
 if (ap_find_token(r->pool, conn, "upgrade")) {
and looked for inconsistencies.

When digging deeper, I found that "Connection Upgrade" was used in most 
cases in httpd. That's why I reverted.


The only places where I found the lowercase version are:
  core.c:5366:   if (ap_find_token(r->pool, conn, "upgrade")) {
  ssl_engine_kernel.c:1344:  apr_table_mergen(r->headers_out, 
"Connection", "upgrade");

  http2: in different places

So, for consistency, it's maybe these places that should be updated???


In any case, I don't think that it would avoid some case folding.
For "Connection upgrade", the only places I've found that process it is 
the one given above (core.c:5366)
In this case, taking advantage of a lower case version would require to 
tweak ap_find_token.
This would, IMHO, add complexity to the code and would be worse for the 
common case (i.e. if what we have does not match what we test, we would 
test twice)



If having upgrade in lower case makes it way, other places should also 
be looked at:

Upgrade: WebSocketvswebsocket

CJ


Le 20/11/2015 00:24, William A Rowe Jr a écrit :
It wouldn't hurt to change this though, the tokens are generally 
represented in lowercase, and this could avoid case folding I suppose.


How often do we see value tokens as upper case from httpd? Let's be 
consistent although it isn't strictly required.




On Thu, Nov 19, 2015 at 3:54 PM, > wrote:


Author: jailletc36
Date: Thu Nov 19 21:54:48 2015
New Revision: 1715294

URL: http://svn.apache.org/viewvc?rev=1715294=rev
Log:
Revert r1715289 (Connection header field should use "upgrade"
instead of "Upgrade")

This is case-insensitive, so no need for such a change.

Modified:
httpd/httpd/trunk/server/core.c

Modified: httpd/httpd/trunk/server/core.c
URL:

http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1715294=1715293=1715294=diff

==
--- httpd/httpd/trunk/server/core.c (original)
+++ httpd/httpd/trunk/server/core.c Thu Nov 19 21:54:48 2015
@@ -5379,7 +5379,7 @@ static int core_upgrade_handler(request_
 /* Let the client know what we are upgrading
to. */
 apr_table_clear(r->headers_out);
 apr_table_setn(r->headers_out, "Upgrade",
protocol);
-apr_table_setn(r->headers_out, "Connection",
"upgrade");
+apr_table_setn(r->headers_out, "Connection",
"Upgrade");

 r->status = HTTP_SWITCHING_PROTOCOLS;
 r->status_line = ap_get_status_line(r->status);
@@ -5404,7 +5404,7 @@ static int core_upgrade_handler(request_
 if (upgrades && upgrades->nelts > 0) {
 char *protocols = apr_array_pstrcat(r->pool,
upgrades, ',');
 apr_table_setn(r->headers_out, "Upgrade", protocols);
-apr_table_setn(r->headers_out, "Connection", "upgrade");
+apr_table_setn(r->headers_out, "Connection", "Upgrade");
 }
 }








Re: svn commit: r1703305 - /httpd/httpd/trunk/modules/aaa/mod_auth_digest.c

2015-10-06 Thread Marion &amp; Christophe JAILLET



Le 05/10/2015 12:03, Plüm, Rüdiger, Vodafone Group a écrit :



-Original Message-
From: Marion & Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
Sent: Samstag, 3. Oktober 2015 21:57
To: dev@httpd.apache.org
Subject: Re: svn commit: r1703305 -
/httpd/httpd/trunk/modules/aaa/mod_auth_digest.c


Le 01/10/2015 20:32, Ruediger Pluem a écrit :

On 09/16/2015 12:20 AM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Tue Sep 15 22:20:45 2015
New Revision: 1703305

URL: http://svn.apache.org/r1703305
Log:
Remove code related to 'AuthDigestEnableQueryStringHack'

This has been undocumented for about 3 years now (see r1415960)

Modified:
  httpd/httpd/trunk/modules/aaa/mod_auth_digest.c

Could this cause

t/modules/digest.t

test 9 to fail?

As we removed the code for good reason we should also remove the test if

this is the case then.

Regards

Rüdiger

Hi,
yes, you are right.

I would proposed the below patch:

+1


Regards

Rüdiger



Done in r1706952

CJ


Re: svn commit: r1703305 - /httpd/httpd/trunk/modules/aaa/mod_auth_digest.c

2015-10-03 Thread Marion &amp; Christophe JAILLET


Le 01/10/2015 20:32, Ruediger Pluem a écrit :

On 09/16/2015 12:20 AM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Tue Sep 15 22:20:45 2015
New Revision: 1703305

URL: http://svn.apache.org/r1703305
Log:
Remove code related to 'AuthDigestEnableQueryStringHack'

This has been undocumented for about 3 years now (see r1415960)

Modified:
 httpd/httpd/trunk/modules/aaa/mod_auth_digest.c

Could this cause

t/modules/digest.t

test 9 to fail?

As we removed the code for good reason we should also remove the test if this 
is the case then.

Regards

Rüdiger


Hi,
yes, you are right.

I would proposed the below patch:


Index: t/modules/digest.t
===
--- t/modules/digest.t(révision 1706466)
+++ t/modules/digest.t(copie de travail)
@@ -111,14 +111,20 @@
 # finally, the MSIE tests

 {
-  # fake current MSIE behavior - this should work as of 2.0.51
-  my $response = GET "$url?$query",
-   Authorization => $no_query_auth,
-   'X-Browser'   => 'MSIE';
-
-  ok t_cmp($response->code,
-   200,
-   'manual Authorization with no query string in header + MSIE');
+  if (have_min_apache_version("2.5.0")) {
+skip "'AuthDigestEnableQueryStringHack' has been removed in r1703305";
+  }
+  else
+  {
+# fake current MSIE behavior - this should work as of 2.0.51
+my $response = GET "$url?$query",
+ Authorization => $no_query_auth,
+ 'X-Browser'   => 'MSIE';
+
+ok t_cmp($response->code,
+ 200,
+ 'manual Authorization with no query string in header + MSIE');
+  }
 }

 {



This way, the test would still be done on 2.4.x where 
AuthDigestEnableQueryStringHack is still present, but not on trunk where 
I've removed it.


As I've never modified the test framework itself, please let me know if 
it is the correct way to do?


Best regards,
CJ


Re: svn commit: r1705492 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/ include/ server/ server/mpm/event/ server/mpm/netware/ server/mpm/prefork/ server/mpm/winnt/ server/mpm/worker/

2015-09-28 Thread Marion &amp; Christophe JAILLET



Le 28/09/2015 21:54, Ruediger Pluem a écrit :

Modified: httpd/httpd/branches/2.4.x/include/ap_mmn.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/include/ap_mmn.h?rev=1705492=1705491=1705492=diff
==
--- httpd/httpd/branches/2.4.x/include/ap_mmn.h (original)
+++ httpd/httpd/branches/2.4.x/include/ap_mmn.h Sat Sep 26 22:20:14 2015
@@ -445,6 +445,11 @@
   * 20120211.46 (2.4.13-dev) Add ap_map_http_request_error()
   * 20120211.47 (2.4.13-dev) Add ap_some_authn_required, ap_force_authn hook.
   *  Deprecate broken ap_some_auth_required.
+ * 20120211.48 (2.4.13-dev) Added ap_log_mpm_common().
+ * 20120211.49 (2.4.13-dev) Add listener bucket in scoreboard.h's 
process_score.
+ * 20120211.50 (2.4.13-dev) Add ap_set_listencbratio(), 
ap_close_listeners_ex(),
+ *  ap_duplicate_listeners(), ap_num_listen_buckets and
+ *  ap_have_so_reuseport to ap_listen.h.
   */
Shouldn't this be 2.4.17-dev instead of 1.4.13-dev?

Regards

Rüdiger


+1

I also spotted it yesterday while looking at potential backport proposal 
for 2.4.x

BTW, 20120211.47 should be 2.4.14-dev

CJ


Re: svn commit: r1705492 - in /httpd/httpd/branches/2.4.x: ./ docs/manual/mod/ include/ server/ server/mpm/event/ server/mpm/netware/ server/mpm/prefork/ server/mpm/winnt/ server/mpm/worker/

2015-09-27 Thread Marion &amp; Christophe JAILLET

Hi,

should r1629916 also be included?
The changelog says that it is a follow up to r1629909, which is included 
in the patch below.


CJ

Le 27/09/2015 00:20, minf...@apache.org a écrit :

Author: minfrin
Date: Sat Sep 26 22:20:14 2015
New Revision: 1705492

URL: http://svn.apache.org/viewvc?rev=1705492=rev
Log:
MPMs: Support SO_REUSEPORT to create multiple duplicated listener
records for scalability.

Submitted by: Yingqi Lu , Jeff Trawick,
   Jim Jagielski, Yann Ylavic

Reviewed by: ylavic, jim, minfrin

Modified:
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/docs/manual/mod/mpm_common.xml
 httpd/httpd/branches/2.4.x/include/ap_listen.h
 httpd/httpd/branches/2.4.x/include/ap_mmn.h
 httpd/httpd/branches/2.4.x/include/http_log.h
 httpd/httpd/branches/2.4.x/include/scoreboard.h
 httpd/httpd/branches/2.4.x/server/listen.c
 httpd/httpd/branches/2.4.x/server/log.c
 httpd/httpd/branches/2.4.x/server/mpm/event/event.c
 httpd/httpd/branches/2.4.x/server/mpm/netware/mpm_netware.c
 httpd/httpd/branches/2.4.x/server/mpm/prefork/prefork.c
 httpd/httpd/branches/2.4.x/server/mpm/winnt/mpm_winnt.c
 httpd/httpd/branches/2.4.x/server/mpm/worker/worker.c





Re: svn commit: r1694950 - in /httpd/httpd/trunk: include/http_request.h modules/http/http_request.c

2015-08-09 Thread Marion Christophe JAILLET

Hi,

doesn't it require a minor ap_mmn.h bump ?

cj

Le 10/08/2015 05:30, gsm...@apache.org a écrit :

Author: gsmith
Date: Mon Aug 10 03:30:25 2015
New Revision: 1694950

URL: http://svn.apache.org/r1694950
Log:
ap_process_request needs exportation for use in mod_h2 on Windows

Modified:
 httpd/httpd/trunk/include/http_request.h
 httpd/httpd/trunk/modules/http/http_request.c

Modified: httpd/httpd/trunk/include/http_request.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_request.h?rev=1694950r1=1694949r2=1694950view=diff
==
--- httpd/httpd/trunk/include/http_request.h (original)
+++ httpd/httpd/trunk/include/http_request.h Mon Aug 10 03:30:25 2015
@@ -316,7 +316,7 @@ AP_DECLARE(void) ap_allow_standard_metho
   * the response to the client
   * @param r The current request
   */
-void ap_process_request(request_rec *r);
+AP_DECLARE(void) ap_process_request(request_rec *r);
  
  /* For post-processing after a handler has finished with a request.

   * (Commonly used after it was suspended)

Modified: httpd/httpd/trunk/modules/http/http_request.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_request.c?rev=1694950r1=1694949r2=1694950view=diff
==
--- httpd/httpd/trunk/modules/http/http_request.c (original)
+++ httpd/httpd/trunk/modules/http/http_request.c Mon Aug 10 03:30:25 2015
@@ -363,7 +363,7 @@ void ap_process_async_request(request_re
  ap_process_request_after_handler(r);
  }
  
-void ap_process_request(request_rec *r)

+AP_DECLARE(void) ap_process_request(request_rec *r)
  {
  apr_bucket_brigade *bb;
  apr_bucket *b;





Re: Issue with bugzilla for BZ #57992 and #57993

2015-06-30 Thread Marion Christophe JAILLET

Should have read the whole message...
Sent to bugzilla-ad...@apache.org

CJ

Le 01/07/2015 07:08, Christophe JAILLET a écrit :

Hi,

I wanted to CLOSE bug #57992 and #57993 as INVALID.

Strangely, they apparently have never been sent to 
b...@httpd.apache.org (at least according to the mail archive I use)
Moreover, when I try to CLOSE them, I get an error, even if the state 
is correctly changed.


I don't really know who to send this report to... so here it is.

Best regards,
CJ


ASF Bugzilla has encountered an internal error. You may have found a 
bug in ASF Bugzilla! Or, you may have followed a deep link that 
contains information Bugzilla doesn't understand. Remember: *Garbage 
In, Garbage Out!*


If you are sure that you didn't cause this error, please save this 
page and send it to bugzilla-ad...@apache.org with details of what you 
were doing at the time this message appeared. We *especially* want to 
know the URL of the page you were on before you got this message.


*Attention Tomcat 5 Users:* The default home page of Tomcat 5 contains 
a link that is supposed to give you a list of open bugs. Instead, you 
get this message, which is not what you came here for. This issue has 
been reported as Tomcat 5 Bug 33117 
http://issues.apache.org/bugzilla/show_bug.cgi?id=33117 and has been 
fixed for the next release.


URL: https://bz.apache.org/bugzilla/process_bug.cgi

undef error - This shouldn't happen at 
/usr/share/perl/5.18/Text/Wrap.pm line 84.








Re: svn commit: r1683044 - /httpd/httpd/trunk/server/core.c

2015-06-04 Thread Marion Christophe JAILLET

Hi,

Skip a few bytes before calling 'strchr' if we know that they can't match.
=
in 'ap_resolve_env', at line 1265 we have:
if (*s == '$') {
if (s[1] == '{'  (e = ap_strchr_c(s, '}'))) {
So, we looking for an ending '}', we alreay know that the 2 first 
caracters are '$' and '{'

No need to scan them again. They can't match a '}'
So, I proposed to start the scan after these 2 bytes (i.e. 
ap_strchr_c(s+2, '}')



s/apr_pstrndup/apr_pstrmemdup/ when applicable.
==
#1) The line after, we apr_pstrndup what was within the '${' and '}'.
We know that (e-s-2) is shorter or equals to the length of '*s'.
So, pstrndup can be replaced by apr_pstrmemdup in order to avoid a 
useless call to strlen.



#2) in 'ap_limit_section' line 2139 we have:
   const char *endp = ap_strrchr_c(arg, '');
Then we check if the '' has been found at line 2146.

So, we know that (endp - arg) is shorter or equals to the length of 
'arg' and that pstrndup can be replaced by apr_pstrmemdup in order to 
avoid a useless call to strlen.



Fix a comment typo.
==
resorce  -- resource



I agree that the wording of the Changelog could be more meaningful. 
Apparently these functions are only used during conf parsing. So, I 
propose to turn is into:
Small speed optimization when parsing Limit, LimitExcept and 
environment variables


Regards,
CJ


Le 03/06/2015 09:05, William A Rowe Jr a écrit :


I tried to reconcile your patch with your svn log entry and I failed.  
Could you either correct or explain further?


TIA,

Bill

On Jun 2, 2015 12:40 AM, jaillet...@apache.org 
mailto:jaillet...@apache.org wrote:


Author: jailletc36
Date: Tue Jun  2 05:40:57 2015
New Revision: 1683044

URL: http://svn.apache.org/r1683044
Log:
Skip a few bytes before calling 'strchr' if we know that they
can't match.
s/apr_pstrndup/apr_pstrmemdup/ when applicable.
Fix a comment typo.

Modified:
httpd/httpd/trunk/server/core.c

Modified: httpd/httpd/trunk/server/core.c
URL:

http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1683044r1=1683043r2=1683044view=diff

==
--- httpd/httpd/trunk/server/core.c (original)
+++ httpd/httpd/trunk/server/core.c Tue Jun  2 05:40:57 2015
@@ -1263,8 +1263,8 @@ AP_DECLARE(const char *) ap_resolve_env(
 }

 if (*s == '$') {
-if (s[1] == '{'  (e = ap_strchr_c(s, '}'))) {
-char *name = apr_pstrndup(p, s+2, e-s-2);
+if (s[1] == '{'  (e = ap_strchr_c(s+2, '}'))) {
+char *name = apr_pstrmemdup(p, s+2, e-s-2);
 word = NULL;
 if (server_config_defined_vars)
 word =
apr_table_get(server_config_defined_vars, name);
@@ -2147,7 +2147,7 @@ AP_CORE_DECLARE_NONSTD(const char *) ap_
 return unclosed_directive(cmd);
 }

-limited_methods = apr_pstrndup(cmd-temp_pool, arg, endp - arg);
+limited_methods = apr_pstrmemdup(cmd-temp_pool, arg, endp -
arg);

 if (!limited_methods[0]) {
 return missing_container_arg(cmd);
@@ -2164,7 +2164,7 @@ AP_CORE_DECLARE_NONSTD(const char *) ap_
 return TRACE cannot be controlled by Limit, see
TraceEnable;
 }
 else if (methnum == M_INVALID) {
-/* method has not been registered yet, but resorce
restriction
+/* method has not been registered yet, but resource
restriction
  * is always checked before method handling, so
register it.
  */
 methnum = ap_method_register(cmd-pool,






Re: [VOTE] Simplified 2.2.x EOL Decision

2015-05-27 Thread Marion Christophe JAILLET



Le 28/05/2015 06:44, William A Rowe Jr a écrit :

Choose one;

[ ] EOL the 2.2.x branch effective 5/31/16; strictly security releases 
to that date
[X] Defer a 2.2.x EOL decision for 6 months and re-consider this 
proposal in Nov, '15.







Re: svn commit: r1673904 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/mod/mod_logio.xml modules/loggers/mod_logio.c

2015-04-15 Thread Marion Christophe JAILLET

Hi,

compatibility note is missing in the doc.

BTW, what is the reason of the LogIOTrackTTFB directive? No impact on 
performance if %^FB is not needed?


CJ

Le 15/04/2015 19:59, cove...@apache.org a écrit :

Author: covener
Date: Wed Apr 15 17:59:42 2015
New Revision: 1673904

URL: http://svn.apache.org/r1673904
Log:
Merge r1671918, r1673113 from trunk:

allow time to first byte (of response headers)
to be logged by mod_logio.

mod_logio was just a conveninent place to do this
w/o writing a new filter or complicating an existing
important one.



Use 'unsigned int' in bitfield

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml
 httpd/httpd/branches/2.4.x/modules/loggers/mod_logio.c

Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml?rev=1673904r1=1673903r2=1673904view=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_logio.xml Wed Apr 15 
17:59:42 2015
@@ -72,6 +72,12 @@
  tdBytes transferred (received and sent), including request and 
headers,
  cannot be zero. This is the combination of %I and %O.br /
  Available in Apache 2.4.7 and later/td/tr
+
+trtdcode%^FB/code/td
+tdDelay in microseconds between when the request arrived and the
+first byte of the response headers are written.  Only available if
+directiveLogIOTrackTTFB/directive is set to ON.
+/td/tr
  /table
  
  pUsually, the functionality is used like this:/p

@@ -83,4 +89,21 @@
  /dl
  /section
  
+directivesynopsis

+nameLogIOTrackTTFB/name
+descriptionEnable tracking of time to first byte (TTFB)/description
+syntaxLogIOTrackTTFB ON|OFF/syntax
+defaultLogIOTrackTTFB OFF/default
+contextlistcontextserver config/contextcontextvirtual host/context
+contextdirectory/contextcontext.htaccess/context/contextlist
+overridenone/override
+
+usage
+pThis directive configures whether this module tracks the delay
+between the request being read and the first byte of the response
+headers being written.  The resulting value may be logged with the
+code%^FB/code format./p
+/usage
+/directivesynopsis
+
  /modulesynopsis


Re: svn commit: r1661409 - in /httpd/httpd/branches/2.4.x/docs/manual: ./ mod/ platform/ rewrite/

2015-02-22 Thread Marion Christophe JAILLET


Le 21/02/2015 18:21, lgen...@apache.org a écrit :

Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_auth_form.html.fr
URL:http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_auth_form.html.fr?rev=1661409r1=1661408r2=1661409view=diff
==
--- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_auth_form.html.fr (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_auth_form.html.fr Sat Feb 21 
17:21:24 2015
@@ -43,9 +43,9 @@
en compte avant d'activer les sessions sur votre serveur./p
  /div
  
-pCe module permet de restreindre les accès, au moyen d'un formulaire de

-connexion HTML, en recherchant les utilisateurs auprès des fournisseurs
-spécifiés. Les formulaires HTML requièrent
+pCe module permet de restreindre l'accès en recherchant les
+utilisateurs dans les fournisseurs spécifiés à l'aide d'un
+formulaire de connexion HTML. Les formulaires HTML requièrent
  davantage de configuration que les méthodes d'authentification
  alternatives, mais ils peuvent s'avérer beaucoup plus conviviaux
  pour les utilisateurs.
@@ -114,7 +114,7 @@ l'authentification/a/li
code class=modulea 
href=../mod/mod_session_cookie.htmlmod_session_cookie/a/code, et l'authentification utilise
un fichier en s'appuyant sur le module
code class=modulea 
href=../mod/mod_authn_file.htmlmod_authn_file/a/code. Si l'authentification échoue,
-  l'utilisateur sera redirigé vers la page du formulaire de
+  l'utilisateur dera redirigé vers la page du formulaire de


Typo


Re: New to Apache

2015-01-22 Thread Marion Christophe JAILLET

Hi,

if you don't have any idea yet on what you would like to work on, maybe 
a good start is to go thrue our bugzilla.

Look at subjects you understand or that seem easy.
If a patch is already proposed you can try and test it, then report any 
feedback.

If no patch is available, you can propose one yourself.
I can give you a list a easy looking subject I have spotted in 
bugzilla if you wish.


Any proposal on memory reduction usage is also welcome.

CJ


tmaybe
Le 23/01/2015 00:31, Paawan Mukker a écrit :
Hi everyone I'm new to open source development and Apache and I wanted 
to contribute to it. Can anyone get me started.

PS - I've already had looked on the stuff on the website.




Re: svn commit: r1651084 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS include/ap_mmn.h include/http_log.h server/log.c

2015-01-12 Thread Marion Christophe JAILLET

Hi,

the commit message is wrong for this one. Cut'n paste error from the 
previous one.

Won't have time myself to fix it in the comming days.

Best regards
CJ



Le 12/01/2015 14:39, j...@apache.org a écrit :

Author: jim
Date: Mon Jan 12 13:39:07 2015
New Revision: 1651084

URL: http://svn.apache.org/r1651084
Log:
Merge r1643825 from trunk:

* core: Fix -D[efined] or Define[d] variables lifetime accross restarts.
 PR 57328.

Submitted-by: Armin Abfalterer a.abfalterer gmail.com
Reviewed/Committed-by: ylavic

Submitted by: ylavic
Reviewed/backported by: jim

Modified:
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/include/ap_mmn.h
 httpd/httpd/branches/2.4.x/include/http_log.h
 httpd/httpd/branches/2.4.x/server/log.c

Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1651084r1=1651083r2=1651084view=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Mon Jan 12 13:39:07 2015
@@ -46,6 +46,9 @@ Changes with Apache 2.4.11
*) mod_ssl: Fix recognition of OCSP stapling responses that are encoded
   improperly or too large.  [Jeff Trawick]
  
+  *) core: Add ap_log_data(), ap_log_rdata(), etc. for logging buffers.

+ [Jeff Trawick]
+
*) mod_proxy_fcgi, mod_authnz_fcgi: stop reading the response and issue an
   error when parsing or forwarding the response fails. [Yann Ylavic]





Re: svn commit: r1638879 - /httpd/httpd/trunk/server/mpm/event/event.c

2014-11-15 Thread Marion Christophe JAILLET

Done in r1639960.

CJ

Le 15/11/2014 08:32, Marion  Christophe JAILLET a écrit :

Hi,

the same pattern exists in eventopt.

CJ


Le 12/11/2014 18:32, cove...@apache.org a écrit :

Author: covener
Date: Wed Nov 12 17:32:24 2014
New Revision: 1638879

URL: http://svn.apache.org/r1638879
Log:
avoid dereferencing a recently apr_pool_clear()'ed event_conn_state_t 
*cs

in several paths where ptrans is being recycled at the end of a request.


Modified:
 httpd/httpd/trunk/server/mpm/event/event.c

Modified: httpd/httpd/trunk/server/mpm/event/event.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=1638879r1=1638878r2=1638879view=diff
== 


--- httpd/httpd/trunk/server/mpm/event/event.c (original)
+++ httpd/httpd/trunk/server/mpm/event/event.c Wed Nov 12 17:32:24 2014
@@ -852,6 +852,7 @@ static int start_lingering_close_common(
  rv = apr_pollset_add(event_pollset, cs-pfd);
  apr_thread_mutex_unlock(timeout_mutex);
  if (rv != APR_SUCCESS  !APR_STATUS_IS_EEXIST(rv)) {
+apr_pool_t *p = cs-p;
  ap_log_error(APLOG_MARK, APLOG_ERR, rv, ap_server_conf,
   start_lingering_close: apr_pollset_add 
failure);

  apr_thread_mutex_lock(timeout_mutex);
@@ -859,7 +860,7 @@ static int start_lingering_close_common(
  apr_thread_mutex_unlock(timeout_mutex);
  apr_socket_close(cs-pfd.desc.s);
  apr_pool_clear(cs-p);
-ap_push_pool(worker_queue_info, cs-p);
+ap_push_pool(worker_queue_info, p);
  return 0;
  }
  return 1;

[...]





Re: svn commit: r1638879 - /httpd/httpd/trunk/server/mpm/event/event.c

2014-11-14 Thread Marion Christophe JAILLET

Hi,

the same pattern exists in eventopt.

CJ


Le 12/11/2014 18:32, cove...@apache.org a écrit :

Author: covener
Date: Wed Nov 12 17:32:24 2014
New Revision: 1638879

URL: http://svn.apache.org/r1638879
Log:
avoid dereferencing a recently apr_pool_clear()'ed event_conn_state_t *cs
in several paths where ptrans is being recycled at the end of a request.


Modified:
 httpd/httpd/trunk/server/mpm/event/event.c

Modified: httpd/httpd/trunk/server/mpm/event/event.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=1638879r1=1638878r2=1638879view=diff
==
--- httpd/httpd/trunk/server/mpm/event/event.c (original)
+++ httpd/httpd/trunk/server/mpm/event/event.c Wed Nov 12 17:32:24 2014
@@ -852,6 +852,7 @@ static int start_lingering_close_common(
  rv = apr_pollset_add(event_pollset, cs-pfd);
  apr_thread_mutex_unlock(timeout_mutex);
  if (rv != APR_SUCCESS  !APR_STATUS_IS_EEXIST(rv)) {
+apr_pool_t *p = cs-p;
  ap_log_error(APLOG_MARK, APLOG_ERR, rv, ap_server_conf,
   start_lingering_close: apr_pollset_add failure);
  apr_thread_mutex_lock(timeout_mutex);
@@ -859,7 +860,7 @@ static int start_lingering_close_common(
  apr_thread_mutex_unlock(timeout_mutex);
  apr_socket_close(cs-pfd.desc.s);
  apr_pool_clear(cs-p);
-ap_push_pool(worker_queue_info, cs-p);
+ap_push_pool(worker_queue_info, p);
  return 0;
  }
  return 1;

[...]


Re: svn commit: r1632736 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/mod_proxy_http.c

2014-10-18 Thread Marion Christophe JAILLET

Hi,

Isn't there the same kind of potential issue in:
mod_buffer, line 268
mod_cahce, line 687

Best regards,

CJ

Le 18/10/2014 08:57, jaillet...@apache.org a écrit :

Author: jailletc36
Date: Sat Oct 18 06:57:40 2014
New Revision: 1632736

URL: http://svn.apache.org/r1632736
Log:
Merge r1599486 from trunk

mod_proxy_http: Avoid (unlikely) access to freed memory.

Submitted by: ylavic
Reviewed by: ylavic, jorton, rjung
Backported by: jailletc36

Modified:
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c

Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1632736r1=1632735r2=1632736view=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Sat Oct 18 06:57:40 2014
@@ -13,6 +13,8 @@ Changes with Apache 2.4.11
   request headers earlier.  Adds MergeTrailers directive to restore
   legacy behavior.  [Edward Lu, Yann Ylavic, Joe Orton, Eric Covener]
  
+  *) mod_proxy_http: Avoid (unlikely) access to freed memory. [Yann Ylavic]

+
*) http_protocol: fix logic in ap_method_list_(add|remove) in order:
 - to correctly reset bits
 - not to modify the 'method_mask' bitfield unnecessarily

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1632736r1=1632735r2=1632736view=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Sat Oct 18 06:57:40 2014
@@ -108,19 +108,6 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
   2.4.x patch: trunk works
   +1: jkaluza, ylavic, rjung
  
-   * mod_proxy_http: Avoid (unlikely) access to freed memory.

- trunk patch: http://svn.apache.org/r1599486
- 2.4.x patch: trunk works
- +1: ylavic, jorton, rjung (as is)
- covener: I did not look in depth, but is the preceding log message also 
bad?
- ylavic: No, this concerns the next for (;; e = APR_BUCKET_NEXT(e)) 
iteration.
- We could also s/apr_bucket_delete/APR_BUCKET_REMOVE/ instead, but
- stripping some (unhandled) buckets from the source brigade does
- not look correct to me either (brigade *to is to be consumed, but
- *from is still living, the caller may want to reuse it, eg:
- https://issues.apache.org/bugzilla/attachment.cgi?id=31686).
- Should we?
-
 * mod_proxy: Make worker name truncation a non-fatal error.
   trunk patch: http://svn.apache.org/r1621367
http://svn.apache.org/r1621372

Modified: httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c?rev=1632736r1=1632735r2=1632736view=diff
==
--- httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c (original)
+++ httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_http.c Sat Oct 18 
06:57:40 2014
@@ -687,7 +687,6 @@ static apr_status_t proxy_buckets_lifeti
  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00964)
Unhandled bucket type of type %s in
 proxy_buckets_lifetime_transform, e-type-name);
-apr_bucket_delete(e);
  rv = APR_EGENERAL;
  }
  }





Re: svn commit: r1628919 - in /httpd/httpd/trunk: CHANGES modules/filters/mod_substitute.c

2014-10-14 Thread Marion Christophe JAILLET


Le 14/10/2014 19:55, Rainer Jung a écrit :

Am 14.10.2014 um 14:22 schrieb Christophe JAILLET:

Hi,

this patch is in the backport proposal for 2.4.x.

See my remarks below.
The only one that worse it is the one for comparison on new varbuf
length either with  or with =

Best regards,
CJ


Le 02/10/2014 11:50, rj...@apache.org a écrit :

Author: rjung
Date: Thu Oct  2 09:50:24 2014
New Revision: 1628919

URL: http://svn.apache.org/r1628919
Log:
mod_substitute: Make maximum line length configurable.

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/modules/filters/mod_substitute.c

Modified: httpd/httpd/trunk/modules/filters/mod_substitute.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_substitute.c?rev=1628919r1=1628918r2=1628919view=diff 



== 



--- httpd/httpd/trunk/modules/filters/mod_substitute.c (original)
+++ httpd/httpd/trunk/modules/filters/mod_substitute.c Thu Oct  2
09:50:24 2014
@@ -33,6 +33,13 @@
  #define APR_WANT_STRFUNC
  #include apr_want.h
+/*
+ * We want to limit the memory usage in a way that is predictable.
+ * Therefore we limit the resulting length of the line.
+ * This is the default value.
+ */
+#define AP_SUBST_MAX_LINE_LENGTH (128*MAX_STRING_LEN)


Why not use directly 1048576 or (1024*1024) or MBYTE defined below),
should MAX_STRING_LEN change one day?


I'm totally fine with either of your proposals. The chosen form was 
what I found in the code and I didn't want to do an unrelated change. 
but yes, i also had to first find out what the MAX_STRING_LEN is, 
befor I knew, what the actual value was. So setting it to some fixed 
value is clearer. +1 to either 1024*1024 or 1048576.

Up to you.

When I looked at it, I grep'ed source code and the first match was:
   ./srclib/apr/passwd/apr_getpass.c:80:#define MAX_STRING_LEN 256
Only looking at the #define (and not at the file!) I first thought that 
doc was not in lone with code.

later on, I found the correct one in httpd.h :)



That block is followed by first copying regm[0].rm_so to the end of vb 
and then


rv = ap_varbuf_regsub(vb, script-replacement, pos, AP_MAX_REG_MATCH, 
regm, cfg-max_line_length - vb.strlen);


If we start with vb.strlen + regm[0].rm_so == cfg-max_line_length, 
then after appending regm[0].rm_so we have vb.strlen == 
cfg-max_line_length and the last param in ap_varbuf_regsub() gets 0. 
But a 0 there does not mean at most 0 bytes, but instead unlimited 
number of bytes :(


So yes, we could change the condition to a , but we would then need 
to skip over the ap_varbuf_regsub() call below. I think we can keep as 
is but I should add a comment about that special case. OK?



OK, understood.
+1 for a comment if someone, one day, notices it and tries understand if 
it is a mistake or not.



+if (rv != APR_SUCCESS || max  0)
+{
+return SubstituteMaxLineLength must be a non-negative
integer optionally 
+   suffixed with 'k', 'm' or 'g'.;


and 'b' ?


You are right, I probably added the 'b'later while working on it and 
forgot to update the description text.



Was just a minor issue.


Re: svn commit: r1629507 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/cache/mod_cache_socache.c

2014-10-05 Thread Marion Christophe JAILLET

Hi,

apparently this add a new build warning:
   mod_cache_socache.c:1425:6: warning: no previous prototype for 
'socache_status_register' [-Wmissing-prototypes]


Adding static fixes it.

CJ



Le 05/10/2014 19:00, rj...@apache.org a écrit :

Author: rjung
Date: Sun Oct  5 17:00:31 2014
New Revision: 1629507

URL: http://svn.apache.org/r1629507
Log:
mod_cache_socache: Add cache status to server-status.

The status_hook simply calls the status function of
socache, very much like mod_ssl does for the ssl
session cache.

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/docs/log-message-tags/next-number
 httpd/httpd/trunk/modules/cache/mod_cache_socache.c

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1629507r1=1629506r2=1629507view=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Sun Oct  5 17:00:31 2014
@@ -1,6 +1,8 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.0
  
+  *) mod_cache_socache: Add cache status to server-status.  [Rainer Jung]

+
*) mod_ssl: Move OCSP stapling information from a per-certificate store to
   a per-server hash. PR 54357, PR 56919. [Alex Bligh alex alex.org.uk,
   Kaspar Brand]

Modified: httpd/httpd/trunk/docs/log-message-tags/next-number
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-tags/next-number?rev=1629507r1=1629506r2=1629507view=diff
==
--- httpd/httpd/trunk/docs/log-message-tags/next-number (original)
+++ httpd/httpd/trunk/docs/log-message-tags/next-number Sun Oct  5 17:00:31 2014
@@ -1 +1 @@
-2816
+2818

Modified: httpd/httpd/trunk/modules/cache/mod_cache_socache.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_cache_socache.c?rev=1629507r1=1629506r2=1629507view=diff
==
--- httpd/httpd/trunk/modules/cache/mod_cache_socache.c (original)
+++ httpd/httpd/trunk/modules/cache/mod_cache_socache.c Sun Oct  5 17:00:31 2014
@@ -22,6 +22,7 @@
  #include http_config.h
  #include http_log.h
  #include http_core.h
+#include http_protocol.h
  #include ap_provider.h
  #include ap_socache.h
  #include util_filter.h
@@ -30,6 +31,7 @@
  #include util_mutex.h
  
  #include mod_cache.h

+#include mod_status.h
  
  #include cache_socache_common.h
  
@@ -1375,6 +1377,56 @@ static apr_status_t destroy_cache(void *

  return APR_SUCCESS;
  }
  
+static int socache_status_hook(request_rec *r, int flags)

+{
+apr_status_t status = APR_SUCCESS;
+cache_socache_conf *conf = ap_get_module_config(r-server-module_config,
+cache_socache_module);
+if (!conf-provider || !conf-provider-socache_provider ||
+!conf-provider-socache_instance) {
+return DECLINED;
+}
+
+ap_rputs(hr\n
+ table cellspacing=0 cellpadding=0\n
+ trtd bgcolor=\#00\\n
+ bfont color=\#ff\ face=\Arial,Helvetica\
+ mod_cache_socache Status:/font/b\n
+ /td/tr\n
+ trtd bgcolor=\#ff\\n, r);
+
+if (socache_mutex) {
+status = apr_global_mutex_lock(socache_mutex);
+if (status != APR_SUCCESS) {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r, APLOGNO(02816)
+could not acquire lock for cache status);
+}
+}
+
+if (status != APR_SUCCESS) {
+ap_rputs(No cache status data available\n, r);
+} else {
+
conf-provider-socache_provider-status(conf-provider-socache_instance,
+ r, flags);
+}
+
+if (socache_mutex  status == APR_SUCCESS) {
+status = apr_global_mutex_unlock(socache_mutex);
+if (status != APR_SUCCESS) {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r, APLOGNO(02817)
+could not release lock for cache status);
+}
+}
+
+ap_rputs(/td/tr\n/table\n, r);
+return OK;
+}
+
+void socache_status_register(apr_pool_t *p)
+{
+APR_OPTIONAL_HOOK(ap, status_hook, socache_status_hook, NULL, NULL, 
APR_HOOK_MIDDLE);
+}
+
  static int socache_precfg(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t 
*ptmp)
  {
  apr_status_t rv = ap_mutex_register(pconf, cache_socache_id, NULL,
@@ -1384,6 +1436,10 @@ static int socache_precfg(apr_pool_t *pc
  failed to register %s mutex, cache_socache_id);
  return 500; /* An HTTP status would be a misnomer! */
  }
+
+/* Register to handle mod_status status page generation */
+socache_status_register(pconf);
+
  return OK;
  }
  








Re: svn commit: r1629508 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache_socache.c

2014-10-05 Thread Marion Christophe JAILLET

Hi,

is it related to PR57023 ?

CJ

Le 05/10/2014 19:05, rj...@apache.org a écrit :

Author: rjung
Date: Sun Oct  5 17:05:21 2014
New Revision: 1629508

URL: http://svn.apache.org/r1629508
Log:
mod_cache_socache: Change average object size
hint from 32 bytes to 2048 bytes.

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/modules/cache/mod_cache_socache.c

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1629508r1=1629507r2=1629508view=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Sun Oct  5 17:05:21 2014
@@ -1,6 +1,9 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.0
  
+  *) mod_cache_socache: Change average object size hint from 32 bytes to

+ 2048 bytes.  [Rainer Jung]
+
*) mod_cache_socache: Add cache status to server-status.  [Rainer Jung]
  
*) mod_ssl: Move OCSP stapling information from a per-certificate store to


Modified: httpd/httpd/trunk/modules/cache/mod_cache_socache.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_cache_socache.c?rev=1629508r1=1629507r2=1629508view=diff
==
--- httpd/httpd/trunk/modules/cache/mod_cache_socache.c (original)
+++ httpd/httpd/trunk/modules/cache/mod_cache_socache.c Sun Oct  5 17:05:21 2014
@@ -1450,7 +1450,7 @@ static int socache_post_config(apr_pool_
  apr_status_t rv;
  const char *errmsg;
  static struct ap_socache_hints socache_hints =
-{ 64, 32, 6000 };
+{ 64, 2048, 6000 };
  
  for (s = base_server; s; s = s-next) {

  cache_socache_conf *conf =







Re: Coding standards, avoiding vulnerabilities in httpd

2014-09-16 Thread Marion Christophe JAILLET


Le 16/09/2014 22:09, Notes Jonny a écrit :


Hello
I had a quick look at httpd 2.4.10 (couldn't find on the website how 
to site how to checkout the trunk)





See http://httpd.apache.org/dev/devnotes.html

CJ


Re: svn commit: r1621806 - in /httpd/httpd/trunk: modules/loggers/mod_journald.c modules/mappers/mod_negotiation.c modules/proxy/mod_proxy_wstunnel.c server/util_expr_eval.c

2014-09-01 Thread Marion Christophe JAILLET

It is not an issue, it was just to silent some cppcheck warnings.

In these 2 cases, it is obvious that explicitly initializing these 
variables is useless because it is assigned just a few lines after.


Moreover:
   - mod_negotiation.c: set just the line after.
   - mod_proxy_wstunnel.c: the other functions of this module do not 
initialize 'apr_status_t' variables when the use it.



My goal is, little by little, to fix cppcheck warnings when safe or obvious.
cppcheck is updated quite often and reducing the noise helps when new 
findings are reported.


CJ


Le 01/09/2014 20:20, Ruediger Pluem a écrit :

jaillet...@apache.org wrote:

Author: jailletc36
Date: Mon Sep  1 14:40:01 2014
New Revision: 1621806

URL: http://svn.apache.org/r1621806
Log:
Silent some cppcheck warnings.

Modified:
 httpd/httpd/trunk/modules/loggers/mod_journald.c
 httpd/httpd/trunk/modules/mappers/mod_negotiation.c
 httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c
 httpd/httpd/trunk/server/util_expr_eval.c

Modified: httpd/httpd/trunk/modules/mappers/mod_negotiation.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mappers/mod_negotiation.c?rev=1621806r1=1621805r2=1621806view=diff
==
--- httpd/httpd/trunk/modules/mappers/mod_negotiation.c (original)
+++ httpd/httpd/trunk/modules/mappers/mod_negotiation.c Mon Sep  1 14:40:01 2014
@@ -1707,7 +1707,7 @@ static void set_language_quality(negotia
   * we are allowed to use the prefix of in HTTP/1.1
   */
  char *lang = ((char **) (variant-content_languages-elts))[j];
-int idx = -1;
+int idx;

What exactly is the issue with an initialized variable?

  
  /* If we wish to fallback or

   * we use our own LanguagePriority index.

Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c?rev=1621806r1=1621805r2=1621806view=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c Mon Sep  1 14:40:01 
2014
@@ -318,7 +318,7 @@ static int proxy_wstunnel_request(apr_po
  apr_uri_t *uri,
  char *url, char *server_portstr, char *scheme)
  {
-apr_status_t rv = APR_SUCCESS;
+apr_status_t rv;

What exactly is the issue with an initialized variable?


  apr_pollset_t *pollset;
  apr_pollfd_t pollfd;
  conn_rec *c = r-connection;


Regards

Rüdiger





Re: svn commit: r1612653 - /httpd/httpd/trunk/server/util_pcre.c

2014-07-22 Thread Marion Christophe JAILLET

+1

Le 22/07/2014 23:01, Rainer Jung a écrit :

On 22.07.2014 22:20, Christophe JAILLET wrote:

Hi,

shouldn't the #error just a few lines below be updated as well, to be
more explicit than too old ?


You are right. But what about instead changing the configure pcre 
version test:


Index: configure.in
===
--- configure.in(revision 1611600)
+++ configure.in(working copy)
@@ -236,7 +236,9 @@
   fi
   case `$PCRE_CONFIG --version` in
   [[1-5].*])
-AC_MSG_ERROR([Need at least pcre version 6.0])
+AC_MSG_ERROR([Need at least pcre version 6.7])
+  [6.[0-6]*])
+AC_MSG_ERROR([Need at least pcre version 6.7])
 ;;
   esac
   AC_MSG_NOTICE([Using external PCRE library from $PCRE_CONFIG])

documenting the requirement PCRE = 6.7 and dropping the check (and 
error message) for PCRE_DUPNAMES from server/util_pcre.c.


I got the version number from looking and the old PCRE tags.

Regards,

Rainer


Le 22/07/2014 21:29, rj...@apache.org a écrit :

Author: rjung
Date: Tue Jul 22 19:29:08 2014
New Revision: 1612653

URL: http://svn.apache.org/r1612653
Log:
Clarify comment.

Modified:
 httpd/httpd/trunk/server/util_pcre.c

Modified: httpd/httpd/trunk/server/util_pcre.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_pcre.c?rev=1612653r1=1612652r2=1612653view=diff 



== 



--- httpd/httpd/trunk/server/util_pcre.c (original)
+++ httpd/httpd/trunk/server/util_pcre.c Tue Jul 22 19:29:08 2014
@@ -125,7 +125,7 @@ AP_DECLARE(int) ap_regcomp(ap_regex_t *
  const char *errorptr;
  int erroffset;
  int errcode = 0;
-/* PCRE_DUPNAMES is only present in more recent versions of 
PCRE */

+/* PCRE_DUPNAMES is only present since version 6.7 of PCRE */
  #ifdef PCRE_DUPNAMES
  int options = PCRE_DUPNAMES;
  #else






Re: Question about APLOGNO

2014-07-20 Thread Marion Christophe JAILLET

Hi

I have proposed for backport for 2.4. See STATUS.
http://svn.apache.org/r1611978
http://svn.apache.org/r1612068
should merge without any trouble and should not generate any conflict 
with code only in trunk, should it be backported one day.


What I have submitted and not proposed for backport yet are:
http://svn.apache.org/r1611980 -- depends of r1608202
http://svn.apache.org/r1611979 -- depends of r1610814


My may concern is to keep 2.4 and trunk as close as possible, but should 
I also see what can be backported to 2.2 ?



Best regards,
CJ


Le 20/07/2014 15:25, William A. Rowe Jr. a écrit :

I'd strongly encourage backporting, if accepted on 2.x branch.

The APn code exists to find guidance through web, email archives 
and forum searches.  Keeping these consistent between 2.4 and 2.next 
is crucial.


It also ensures further backports apply without a host of future 
conflicts.



Christophe JAILLET christophe.jail...@wanadoo.fr wrote:

Le 19/07/2014 22:44, William A. Rowe Jr. a écrit :

 If it violates 80 col formatting style rule, absolutely do not shift
 the APLOGNO macro to the first line.

Sure.

Moreover, when submitting patches, I'll take care to only propose things
that can be backported easily.
Changes relying on other changes, not backported yet, will either be
submitted as individual patches or will remain in my tree.
Same for changes that could generate conflict when merging other
changes, should they be backported one day.

Best regards,
CJ




Re: svn commit: r1611252 - /httpd/httpd/trunk/include/util_varbuf.h

2014-07-17 Thread Marion Christophe JAILLET

Thanks Mike,

Both have been fixed.

CJ

Le 17/07/2014 21:50, Mike Rumph a écrit :

A few comments on typos below:

On 7/16/2014 10:34 PM, jaillet...@apache.org wrote:
Improve layout, add trailing '.' in function description, capitalize 
first letter of description, fix typo, turn \0 into \\0.
Move the detailled description after @defgroup so that it is taken 
into account.

s/detailled/detailed/

Modified:
 httpd/httpd/trunk/include/util_varbuf.h

Modified: httpd/httpd/trunk/include/util_varbuf.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/util_varbuf.h?rev=1611252r1=1611251r2=1611252view=diff
== 


--- httpd/httpd/trunk/include/util_varbuf.h (original)
+++ httpd/httpd/trunk/include/util_varbuf.h Thu Jul 17 05:34:12 2014
@@ -42,87 +43,93 @@ extern C {

.
-/** initialize a resizable buffer. It is safe to re-initialize a 
prevously
- *  used ap_varbuf. The old buffer will be released when the 
corresponding
- *  pool is cleared. The buffer remains usable until the pool is 
cleared,
- *  even if the ap_varbuf was located on the stack and has gone out 
of scope.
- * @param pool the pool to allocate small buffers from and to 
register the

- *cleanup with
- * @param vb pointer to the ap_varbuf struct
- * @param init_size the initial size of the buffer (see 
ap_varbuf_grow() for details)

+/**
+ * Initialize a resizable buffer. It is safe to re-initialize a 
prevously

s/prevously/previously/
+ * used ap_varbuf. The old buffer will be released when the 
corresponding
+ * pool is cleared. The buffer remains usable until the pool is 
cleared,
+ * even if the ap_varbuf was located on the stack and has gone out 
of scope.
+ * @param   poolThe pool to allocate small buffers from and 
to register

+ *  the cleanup with
+ * @param   vb  Pointer to the ap_varbuf struct
+ * @param   init_size   The initial size of the buffer (see 
ap_varbuf_grow() for

+ *  details)
   */
  AP_DECLARE(void) ap_varbuf_init(apr_pool_t *pool, struct ap_varbuf 
*vb,

  apr_size_t init_size);








Re: svn commit: r1610509 - /httpd/httpd/trunk/modules/generators/mod_cgid.c

2014-07-14 Thread Marion Christophe JAILLET

Hi,

no APLOGNO ?

Best regards,
CJ

Le 14/07/2014 22:08, cove...@apache.org a écrit :

Author: covener
Date: Mon Jul 14 20:08:25 2014
New Revision: 1610509

URL: http://svn.apache.org/r1610509
Log:
*) SECURITY: CVE-2014-0231 (cve.mitre.org)
mod_cgid: Fix a denial of service against CGI scripts that do
not consume stdin that could lead to lingering HTTPD child processes
filling up the scoreboard and eventually hanging the server.
[Rainer Jung, Eric Covener, Yann Ylavic]

Submitted By: rjung, covener, ylavic
Reviewed By: trawick, jorton, covener, jim



Modified:
 httpd/httpd/trunk/modules/generators/mod_cgid.c

Modified: httpd/httpd/trunk/modules/generators/mod_cgid.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/generators/mod_cgid.c?rev=1610509r1=1610508r2=1610509view=diff
==
--- httpd/httpd/trunk/modules/generators/mod_cgid.c (original)
+++ httpd/httpd/trunk/modules/generators/mod_cgid.c Mon Jul 14 20:08:25 2014
@@ -1551,6 +1551,10 @@ static int cgid_handler(request_rec *r)
  if (rv != APR_SUCCESS) {
  /* silly script stopped reading, soak up remaining message */
  child_stopped_reading = 1;
+ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r,
+  Error writing request body to script %s,
+  r-filename);
+
  }


Re: svn commit: r1610509 - /httpd/httpd/trunk/modules/generators/mod_cgid.c

2014-07-14 Thread Marion Christophe JAILLET


Le 14/07/2014 22:28, Eric Covener a écrit :

On Mon, Jul 14, 2014 at 4:27 PM, Marion  Christophe JAILLET
christophe.jail...@wanadoo.fr wrote:

Hi,

no APLOGNO ?

ty, can you help remedy in trunk and 2.4?


np. I also have added empty APLOGNO in mod_deflate + fix a comment.

r1610518 in trunk
r1610522 in 2.4.x

CJ


Re: svn commit: r1608762 - in /httpd/httpd/branches/2.4.x: ./ CHANGES modules/proxy/proxy_util.c

2014-07-08 Thread Marion Christophe JAILLET


Le 08/07/2014 15:16, j...@apache.org a écrit :

Author: jim
Date: Tue Jul  8 13:16:27 2014
New Revision: 1608762

URL: http://svn.apache.org/r1608762
Log:
Merge r1588519 from trunk:

mod_proxy: When ping/pong is configured for a worker, don't send or forward
100 Continue (interim) response to the client if it does not
expect one.

Submitted by: ylavic
Reviewed/backported by: jim

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c

Propchange: httpd/httpd/branches/2.4.x/
--
   Merged /httpd/httpd/trunk:r1588519

Modified: httpd/httpd/branches/2.4.x/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1608762r1=1608761r2=1608762view=diff
==
--- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original)
+++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Tue Jul  8 13:16:27 2014
@@ -2,6 +2,10 @@
  
  Changes with Apache 2.4.10
  
+  *) mod_proxy: When ping/pong is configured for a worker, don't send or

+ forward 100 Continue (interim) response to the client if it does
+ not expect one. [Yann Ylavic]
+
*) mod_proxy_fcgi: Fix occasional high CPU when handling request bodies.
   [Jeff Trawick]
  


Modified: httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c?rev=1608762r1=1608761r2=1608762view=diff
==
--- httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c Tue Jul  8 13:16:27 
2014
@@ -3307,8 +3307,22 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbr
   * to backend
   */
  if (do_100_continue) {
-apr_table_mergen(r-headers_in, Expect, 100-Continue);
-r-expecting_100 = 1;
+const char *val;
+
+if (!r-expecting_100) {
+/* Don't forward any 100 Continue response if the client is
+ * not expecting it.
+ */
+apr_table_setn(r-subprocess_env, proxy-interim-response,
+  Suppress);
+}
+
+/* Add the Expect header if not already there. */
+if (((val = apr_table_get(r-headers_in, Expect)) == NULL)
+|| (strcasecmp(val, 100-Continue) != 0 // fast path
+ !ap_find_token(r-pool, val, 100-Continue))) {
+apr_table_mergen(r-headers_in, Expect, 100-Continue);
+}
  }
  
  /* X-Forwarded-*: handling


Just a few details :

1) Shouldn't we use 100-continue (lowercase c) instead, to more 
closely match http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html, § 
8.2.3 ?
   This would also be consistent with the use of this string in 
protocol.c



2) if of any use, in the fast path, strcmp could be used instead of 
strcasecmp



3) // fast path, should be /* fast path */


4) in protocol.c, around line 1212 there is:

if (((expect = apr_table_get(r-headers_in, Expect)) != NULL)
 (expect[0] != '\0')) {
/*
 * The Expect header field was added to HTTP/1.1 after RFC 2068
 * as a means to signal when a 100 response is desired and,
 * unfortunately, to signal a poor man's mandatory extension that
 * the server must understand or return 417 Expectation Failed.
 */
if (strcasecmp(expect, 100-continue) == 0) {
r-expecting_100 = 1;
}

this is not consistent with the code below. Should this be changed to 
something like:

if (strcasecmp(expect, 100-continue) == 0 ||
ap_find_token(r-pool, expect, 100-Continue)) {
r-expecting_100 = 1;
}
?


Best regards,
CJ

---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce 
que la protection avast! Antivirus est active.
http://www.avast.com



Re: svn commit: r1604373 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS support/ab.c

2014-06-21 Thread Marion Christophe JAILLET

Hi,

doc should also be updated accordingly + compatibility note should be 
added to state in which version this -m option has been added.



For your information,, I have a pending patch on my computer for missing 
compatibility notes in support applications updated in previous releases.

Will be applied shortly.

CJ

Le 21/06/2014 15:41, traw...@apache.org a écrit :

Author: trawick
Date: Sat Jun 21 13:41:28 2014
New Revision: 1604373

URL:http://svn.apache.org/r1604373
Log:
Merge r1601076 from trunk:

ab: support custom HTTP method with -m argument.

PR: 56604
Submitted by: Roman Jurkov winfinit gmail.com
Reviewed by: ylavic, trawick, covener

(r1601680 and r1601700 not reflected in mergeinfo due to
a collision with an unrelated trunk change)

Modified:
 httpd/httpd/branches/2.4.x/   (props changed)
 httpd/httpd/branches/2.4.x/CHANGES
 httpd/httpd/branches/2.4.x/STATUS
 httpd/httpd/branches/2.4.x/support/ab.c




Re: svn commit: r1598299 - in /httpd/httpd/branches/2.2.x/docs/manual/mod: mod_autoindex.html.fr mod_autoindex.xml.ja mod_autoindex.xml.ko mod_autoindex.xml.tr

2014-05-29 Thread Marion Christophe JAILLET


Le 29/05/2014 16:12, lgen...@apache.org a écrit :

Author: lgentis
Date: Thu May 29 14:11:59 2014
New Revision: 1598299

URL: http://svn.apache.org/r1598299
Log:
Rebuild.

Modified:
 httpd/httpd/branches/2.2.x/docs/manual/mod/mod_autoindex.html.fr

Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/mod_autoindex.html.fr
URL: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/mod/mod_autoindex.html.fr?rev=1598299r1=1598298r2=1598299view=diff
==
--- httpd/httpd/branches/2.2.x/docs/manual/mod/mod_autoindex.html.fr (original)
+++ httpd/httpd/branches/2.2.x/docs/manual/mod/mod_autoindex.html.fr Thu May 29 
14:11:59 2014
@@ -568,7 +568,7 @@ de l'index d'un répertoire/td/tr
  expression avec caractères génériques de style shell ou un nom de
  fichier complet. Plusieurs directives IndexIgnore effectuent des
  ajouts à la liste, et ne remplacent pas la liste des fichiers à
-ignorer. Par défaut, la liste contient code./code (le répertoire
+ignorés. Par défaut, la liste contient code./code (le répertoire
  courant)./p


Hmmm. Vraiment ???
Sinon, il faudrait enlever le à de la ligne précédente.

Idem pour 2.4 et le tronc.

CJ


Re: svn commit: r1594088 - in /httpd/httpd/branches/2.4.x/docs/manual/mod: mod_rewrite.html.en mod_rewrite.xml

2014-05-12 Thread Marion Christophe JAILLET

Hi,

in addition to my patch,

what is listed as specials in RewriteCond Server-Variables is not that 
special to mod_rewrite and are also available here: 
http://httpd.apache.org/docs/2.4/en/expr.html#vars.


So, IMHO, this specials category could be dropped and its items moved 
in the other lists.



Finally, r1132494 stated at the end:
Remaining tasks:
  Write docs.
So it is likely that other things need to be adjusted somewhere else in 
the doc. I've not checked neither what nor where.



Best regards,

CJ

Le 12/05/2014 22:50, jaillet...@apache.org a écrit :

Author: jailletc36
Date: Mon May 12 20:50:34 2014
New Revision: 1594088

URL: http://svn.apache.org/r1594088
Log:
Based on report from Ken Zalewski, on online doc.

Add missing Server-Variables useable in RewriteCond directive.
Introduced in r1132494
CONTEXT_PREFIX
CONTEXT_DOCUMENT_ROOT
Introduced in r737973
IPV6
Missing for ages!
SCRIPT_GROUP
SCRIPT_USER

I have added where I found it logical, feel free to adjust.
I have also reordered this table to ease reading.
Finally, I have beautified some tables at the end.

Modified:
 httpd/httpd/branches/2.4.x/docs/manual/mod/mod_rewrite.html.en
 httpd/httpd/branches/2.4.x/docs/manual/mod/mod_rewrite.xml




Re: svn commit: r1592529 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_scgi.c modules/proxy/proxy_util.c

2014-05-05 Thread Marion Christophe JAILLET

Hi,

why not having SCGI_DEFAULT_PORT in a .h file, just as AJP13_DEF_PORT?
This would avoid using SCGI_DEFAULT_PORT in one place and 4000 in another.

Moreover, this could be renamed as SCGI_DEF_PORT to be consistent with AJP.

Just my 2 cents.

CJ

Le 05/05/2014 16:02, traw...@apache.org a écrit :

Author: trawick
Date: Mon May  5 14:02:48 2014
New Revision: 1592529

URL: http://svn.apache.org/r1592529
Log:
mod_proxy_scgi: Support Unix sockets.

ap_proxy_port_of_scheme(): Support default SCGI port (4000).

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c
 httpd/httpd/trunk/modules/proxy/proxy_util.c

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1592529r1=1592528r2=1592529view=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Mon May  5 14:02:48 2014
@@ -1,6 +1,9 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.0
  
+  *) mod_proxy_scgi: Support Unix sockets.  ap_proxy_port_of_scheme():

+ Support default SCGI port (4000).  [Jeff Trawick]
+
*) mod_proxy_fcgi: Fix occasional high CPU when handling request bodies.
   [Jeff Trawick]
  


Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c?rev=1592529r1=1592528r2=1592529view=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c Mon May  5 14:02:48 2014
@@ -176,13 +176,15 @@ static int scgi_canon(request_rec *r, ch
  {
  char *host, sport[sizeof(:65535)];
  const char *err, *path;
-apr_port_t port = SCGI_DEFAULT_PORT;
+apr_port_t port, def_port;
  
  if (strncasecmp(url, SCHEME ://, sizeof(SCHEME) + 2)) {

  return DECLINED;
  }
  url += sizeof(SCHEME); /* Keep slashes */
  
+port = def_port = SCGI_DEFAULT_PORT;

+
  err = ap_proxy_canon_netloc(r-pool, url, NULL, NULL, host, port);
  if (err) {
  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00857)
@@ -190,7 +192,12 @@ static int scgi_canon(request_rec *r, ch
  return HTTP_BAD_REQUEST;
  }
  
-apr_snprintf(sport, sizeof(sport), :%u, port);

+if (port != def_port) {
+apr_snprintf(sport, sizeof(sport), :%u, port);
+}
+else {
+sport[0] = '\0';
+}
  
  if (ap_strchr(host, ':')) { /* if literal IPv6 address */

  host = apr_pstrcat(r-pool, [, host, ], NULL);

Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1592529r1=1592528r2=1592529view=diff
==
--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Mon May  5 14:02:48 2014
@@ -3514,6 +3514,7 @@ static proxy_schemes_t pschemes[] =
  {
  {fcgi, 8000},
  {ajp,  AJP13_DEF_PORT},
+{scgi, 4000},
  { NULL, 0x } /* unknown port */
  };
  


Re: svn commit: r1592529 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_scgi.c modules/proxy/proxy_util.c

2014-05-05 Thread Marion Christophe JAILLET

Moreover,

all mod_proxy_something that do not append the port when the default is 
used are built this way:


static int FCT_canon(request_rec *r, char *url)
{
[...]
apr_port_t port, def_port;
[...]

if (port != def_port)
apr_snprintf(sport, sizeof(sport), :%d, port);
else
sport[0] = '\0';
[...]
}

All, except scgi, use a :%d. scgi has :%u.

To be consistent, I think that %u should be used in all places.


CJ


Le 05/05/2014 20:59, Marion  Christophe JAILLET a écrit :

Hi,

why not having SCGI_DEFAULT_PORT in a .h file, just as AJP13_DEF_PORT?
This would avoid using SCGI_DEFAULT_PORT in one place and 4000 in 
another.


Moreover, this could be renamed as SCGI_DEF_PORT to be consistent with 
AJP.


Just my 2 cents.

CJ

Le 05/05/2014 16:02, traw...@apache.org a écrit :

Author: trawick
Date: Mon May  5 14:02:48 2014
New Revision: 1592529

URL: http://svn.apache.org/r1592529
Log:
mod_proxy_scgi: Support Unix sockets.

ap_proxy_port_of_scheme(): Support default SCGI port (4000).

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c
 httpd/httpd/trunk/modules/proxy/proxy_util.c

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1592529r1=1592528r2=1592529view=diff
== 


--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Mon May  5 14:02:48 2014
@@ -1,6 +1,9 @@
   -*- 
coding: utf-8 -*-

  Changes with Apache 2.5.0
  +  *) mod_proxy_scgi: Support Unix sockets. ap_proxy_port_of_scheme():
+ Support default SCGI port (4000).  [Jeff Trawick]
+
*) mod_proxy_fcgi: Fix occasional high CPU when handling request 
bodies.

   [Jeff Trawick]

Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c?rev=1592529r1=1592528r2=1592529view=diff
== 


--- httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_scgi.c Mon May  5 
14:02:48 2014

@@ -176,13 +176,15 @@ static int scgi_canon(request_rec *r, ch
  {
  char *host, sport[sizeof(:65535)];
  const char *err, *path;
-apr_port_t port = SCGI_DEFAULT_PORT;
+apr_port_t port, def_port;
if (strncasecmp(url, SCHEME ://, sizeof(SCHEME) + 2)) {
  return DECLINED;
  }
  url += sizeof(SCHEME); /* Keep slashes */
  +port = def_port = SCGI_DEFAULT_PORT;
+
  err = ap_proxy_canon_netloc(r-pool, url, NULL, NULL, host, 
port);

  if (err) {
  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00857)
@@ -190,7 +192,12 @@ static int scgi_canon(request_rec *r, ch
  return HTTP_BAD_REQUEST;
  }
  -apr_snprintf(sport, sizeof(sport), :%u, port);
+if (port != def_port) {
+apr_snprintf(sport, sizeof(sport), :%u, port);
+}
+else {
+sport[0] = '\0';
+}
if (ap_strchr(host, ':')) { /* if literal IPv6 address */
  host = apr_pstrcat(r-pool, [, host, ], NULL);

Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1592529r1=1592528r2=1592529view=diff
== 


--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Mon May  5 14:02:48 
2014

@@ -3514,6 +3514,7 @@ static proxy_schemes_t pschemes[] =
  {
  {fcgi, 8000},
  {ajp,  AJP13_DEF_PORT},
+{scgi, 4000},
  { NULL, 0x } /* unknown port */
  };






Re: svn commit: r1592615 - in /httpd/httpd/trunk/modules/proxy: mod_proxy_scgi.c proxy_util.c scgi.h

2014-05-05 Thread Marion Christophe JAILLET

Thanks :)
The comment also answer a question I had: Where does this default 4000 
comes from?



/** @} */
missing ?

CJ

Le 05/05/2014 21:26, traw...@apache.org a écrit :

Author: trawick
Added: httpd/httpd/trunk/modules/proxy/scgi.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/scgi.h?rev=1592615view=auto
==
--- httpd/httpd/trunk/modules/proxy/scgi.h (added)
+++ httpd/httpd/trunk/modules/proxy/scgi.h Mon May  5 19:26:33 2014
@@ -0,0 +1,34 @@
+/* Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/**
+ * @file scgi.h
+ * @brief Shared SCGI-related definitions
+ *
+ * @ingroup APACHE_INTERNAL
+ * @{
+ */
+
+#ifndef SCGI_H
+#define SCGI_H
+
+/* This is not defined by the protocol.  It is a convention
+ * of mod_proxy_scgi, and mod_proxy utility routines must
+ * use the same value as mod_proxy_scgi.
+ */
+#define SCGI_DEF_PORT 4000
+
+#endif /* SCGI_H */


Re: svn commit: r1588704 - in /httpd/httpd/trunk: CHANGES modules/cache/cache_util.c

2014-04-20 Thread Marion Christophe JAILLET

Hi,

The description and the CHANGES are about AH00784 but the patch is only 
about adding 'status' to AH00783.


-else if (APR_EEXIST == status) {
+else if (APR_STATUS_IS_EEXIST(status)) {
seems not to change anything.

#define APR_STATUS_IS_EEXIST(s)   ((s) == APR_EEXIST)


So, is something missing in the patch or the CHANGES entry should be 
tweaked?



CJ


Le 19/04/2014 22:21, cove...@apache.org a écrit :

Author: covener
Date: Sat Apr 19 20:21:01 2014
New Revision: 1588704

URL: http://svn.apache.org/r1588704
Log:
Fix errors with CacheLock on Windows:

cache_util.c(757): (OS 80)The file exists.  : [client 127.0.0.1:63889]
AH00784: Attempt to obtain a cache lock for stale cached URL failed,
revalidating entry anyway:

Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/modules/cache/cache_util.c

Modified: httpd/httpd/trunk/CHANGES
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1588704r1=1588703r2=1588704view=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Sat Apr 19 20:21:01 2014
@@ -1,6 +1,9 @@
   -*- coding: utf-8 -*-
  Changes with Apache 2.5.0
  
+  *) mod_cache: Fix AH00784 errors on Windows when the the CacheLock directive

+ is enabled.  [Eric Covener]
+
*) mod_proxy: Preserve original request headers even if they differ
   from the ones to be forwarded to the backend. PR 45387.
   [Yann Ylavic]

Modified: httpd/httpd/trunk/modules/cache/cache_util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/cache_util.c?rev=1588704r1=1588703r2=1588704view=diff
==
--- httpd/httpd/trunk/modules/cache/cache_util.c (original)
+++ httpd/httpd/trunk/modules/cache/cache_util.c Sat Apr 19 20:21:01 2014
@@ -240,7 +240,7 @@ CACHE_DECLARE(apr_int64_t) ap_cache_curr
   * Try obtain a cache wide lock on the given cache key.
   *
   * If we return APR_SUCCESS, we obtained the lock, and we are clear to
- * proceed to the backend. If we return APR_EEXISTS, then the lock is
+ * proceed to the backend. If we return APR_EEXIST, then the lock is
   * already locked, someone else has gone to refresh the backend data
   * already, so we must return stale data with a warning in the mean
   * time. If we return anything else, then something has gone pear
@@ -735,9 +735,9 @@ int cache_check_freshness(cache_handle_t
  r-unparsed_uri);
  return 0;
  }
-else if (APR_EEXIST == status) {
+else if (APR_STATUS_IS_EEXIST(status)) {
  /* lock already exists, return stale data anyway, with a warning */
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(00783)
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, status, r, APLOGNO(00783)
  Cache already locked for stale cached URL, 
  pretend it is fresh: %s,
  r-unparsed_uri);







  1   2   >