Re: Can't find definition of ap_run_child_stopping

[Daniel Gruno]

On 2023-08-23 07:02, Emile Cormier wrote:

Hi Everyone,

I'm studying parts of httpd to help me in the development of a TCP 
server I'm working on. In particular, I'm looking at how httpd handles 
socket errors.


Anyway, I've stumbled upon an ap_run_child_stopping function call within 
the signal_threads function 
(https://github.com/apache/httpd/blob/a834e62ebf6279ce9e35193151aec809f7f58df1/server/mpm/worker/worker.c#L332C5-L332C26 ).


For the life of me, I cannot seem to find the definition of 
ap_run_child_stopping. I've downloaded the source tarballs for httpd, 
APR, and APR-util, and performed a find-in-files to no avail (with no 
file extension filtering).


If someone can point me to where ap_run_child_stopping is defined, it 
would be greatly appreciated.


AIUI, it's from a macro, so you won't find it easily in the code (it 
does not exist by that name in there, as it is combined from ap_run_* 
and child_stopping). Maybe 
https://github.com/apache/httpd/blob/a834e62ebf6279ce9e35193151aec809f7f58df1/include/ap_hooks.h#L84 
will help?




Cheers,
Emile Cormier

Re: [VOTE CLOSED] Switch read/write repository from Subversion to Git

[Daniel Gruno]

On 2023-05-11 13:45, Ruediger Pluem wrote:



On 5/11/23 5:40 PM, Daniel Gruno wrote:

On 2023-05-11 10:33, Ruediger Pluem wrote:



On 5/11/23 12:27 PM, Ruediger Pluem wrote:



On 5/4/23 10:34 AM, Ruediger Pluem wrote:

This is a formal vote on whether we should move our read/write repository from 
Subversion to Git.
This means that our latest read/write repository will be no longer available 
via svn.apache.org. It
will be available via Git at https://gitbox.apache.org/repos/asf/httpd-site.git 
and https://github.com/apache/httpd.git.
Github also offers the possibility to use a Subversion client:
https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients


[ ]: Move the read/write repository from Subversion to Git and leverage the 
features of Github (for now Actions and PR).
[ ]: Move the read/write repository from Subversion to Git, but I don't want to 
work with Github and I will only work with
   what gitbox.apache.org offers.
[ ]: Leave everything as is.




After being open for one week I call this vote closed. Thank you for everyone 
who participated in this vote by
either voting directly or voicing opinions on the subject.

Result:

Total number of votes: 16

[ ]: Move the read/write repository from Subversion to Git and leverage the 
features of Github (for now Actions and PR).

13 votes by jorton, ylavic, icing, gbechis, covener, humbedooh, rjung, 
jailletc36, jblond, gstein, rpluem, jim, fielding.

[ ]: Move the read/write repository from Subversion to Git, but I don't want to 
work with Github and I will only work with
    what gitbox.apache.org offers.

0 votes.

[ ]: Leave everything as is.

3 votes by manu, ivan, minfrin.



Now that the vote is closed in favor of moving to Git what are the next steps?
Do we need to open an INFRA ticket to get this done?
Who will open it?


Anyone on the PMC can open such a ticket, there is a canonical thread here to 
prove consensus.


Is there any preferred point of time to do this?


It depends...
The read-only mirror that we currently have _can_ be repurposed as a r/w 
repository, which means the cutover could be quite
instant. I'd advise that folks make the necessary checks and ensure that the 
git repo has accurate history and contents
(specifically the current state of trunk/2.4/etc). When we are satisfied, we 
can ask Infra to switch the mirror over to a
read/write mode. Subversion history will be preserved, and the subversion dir 
will be locked to read-only (assuming we don't have
other resources there we need to write to still).

The bigger task comes after that, as all the source links in docs, our web site 
etc, will need to be updated, but that can happen
after the fact.


Thanks for the process. What about the commit mails currently going to 
c...@httpd.apache.org? Do we need to do something to ensure
that git commits get send there in the future?


All notification schemes and other repository settings for git repos are 
handled via the .asf.yaml metadata file[1] and is entirely self-serve. 
Each repository we have can have individual settings.


[1] https://s.apache.org/asfyaml



Regards

Rüdiger

Re: [VOTE CLOSED] Switch read/write repository from Subversion to Git

[Daniel Gruno]

On 2023-05-11 10:33, Ruediger Pluem wrote:



On 5/11/23 12:27 PM, Ruediger Pluem wrote:



On 5/4/23 10:34 AM, Ruediger Pluem wrote:

This is a formal vote on whether we should move our read/write repository from 
Subversion to Git.
This means that our latest read/write repository will be no longer available 
via svn.apache.org. It
will be available via Git at https://gitbox.apache.org/repos/asf/httpd-site.git 
and https://github.com/apache/httpd.git.
Github also offers the possibility to use a Subversion client:
https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients


[ ]: Move the read/write repository from Subversion to Git and leverage the 
features of Github (for now Actions and PR).
[ ]: Move the read/write repository from Subversion to Git, but I don't want to 
work with Github and I will only work with
  what gitbox.apache.org offers.
[ ]: Leave everything as is.




After being open for one week I call this vote closed. Thank you for everyone 
who participated in this vote by
either voting directly or voicing opinions on the subject.

Result:

Total number of votes: 16

[ ]: Move the read/write repository from Subversion to Git and leverage the 
features of Github (for now Actions and PR).

13 votes by jorton, ylavic, icing, gbechis, covener, humbedooh, rjung, 
jailletc36, jblond, gstein, rpluem, jim, fielding.

[ ]: Move the read/write repository from Subversion to Git, but I don't want to 
work with Github and I will only work with
   what gitbox.apache.org offers.

0 votes.

[ ]: Leave everything as is.

3 votes by manu, ivan, minfrin.



Now that the vote is closed in favor of moving to Git what are the next steps?
Do we need to open an INFRA ticket to get this done?
Who will open it?


Anyone on the PMC can open such a ticket, there is a canonical thread 
here to prove consensus.



Is there any preferred point of time to do this?


It depends...
The read-only mirror that we currently have _can_ be repurposed as a r/w 
repository, which means the cutover could be quite instant. I'd advise 
that folks make the necessary checks and ensure that the git repo has 
accurate history and contents (specifically the current state of 
trunk/2.4/etc). When we are satisfied, we can ask Infra to switch the 
mirror over to a read/write mode. Subversion history will be preserved, 
and the subversion dir will be locked to read-only (assuming we don't 
have other resources there we need to write to still).


The bigger task comes after that, as all the source links in docs, our 
web site etc, will need to be updated, but that can happen after the fact.




Regards

Rüdiger

Re: [VOTE] Switch read/write repository from Subversion to Git

[Daniel Gruno]

On 2023-05-08 16:18, Christopher Schultz wrote:

Graham,

On 5/8/23 05:29, Graham Leggett via dev wrote:

On 04 May 2023, at 09:34, Ruediger Pluem  wrote:

This is a formal vote on whether we should move our read/write 
repository from Subversion to Git.
This means that our latest read/write repository will be no longer 
available via svn.apache.org. It
will be available via Git at 
https://gitbox.apache.org/repos/asf/httpd-site.git and 
https://github.com/apache/httpd.git.

Github also offers the possibility to use a Subversion client:
https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients


[ ]: Move the read/write repository from Subversion to Git and 
leverage the features of Github (for now Actions and PR).
[ ]: Move the read/write repository from Subversion to Git, but I 
don't want to work with Github and I will only work with

 what gitbox.apache.org offers.
[X]: Leave everything as is.


I would rather see proper SVN integration with Github. This is a vote 
of no confidence in our own projects.


I don't see it as an anti-NIH vote or anything like that.

git simply has a bunch of superior features, behaviors, etc. that 
Subversion simply will never have, regardless of any commitment of their 
development team. Sure, the svn team could replicate git, but since git 
already exists, why not use it?


-chris


My 2 cents on this is it's not Git vs Subversion here - it's GitHub vs 
SubversionHub, and the latter doesn't exist. Given how the majority of 
users use GitHub, it really isn't about how Git in any way is 
better/worse than Subversion, it's 99% about the tools that GitHub offer.


VHS vs BetaMax anyone? :)

Re: [VOTE] Switch read/write repository from Subversion to Git

[Daniel Gruno]

On 2023-05-04 07:48, Eric Covener wrote:

[x]: Move the read/write repository from Subversion to Git and
leverage the features of Github (for now Actions and PR).



[x]: Move the read/write repository from Subversion to Git and
 leverage the features of Github (for now Actions and PR).

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

[Daniel Gruno]

On 2023-05-03 14:12, Eric Covener wrote:

On Tue, Apr 25, 2023 at 2:45 PM Graham Leggett via dev
 wrote:


On 25 Apr 2023, at 07:45, Ruediger Pluem  wrote:

2. Switching from Subversion to Git is mostly an emotional problem for me. We 
have some closer ties to Subversion by some
   overlaps in the community and via mod_dav_svn we kind of partially eat our 
very own dogfood here by using Subversion.
   We wouldn't do that any longer with Git. Plus it would switch another of our 
development tools from an Apache license to GPL.
   Apart from technical aspects that this change would create we should check 
if all of the current active committers are fine
   using Github. While people could use Gitbox and thus avoid Github when we 
use Git I would like us to leverage the features of
   Github when we would do this switch and I think this cannot be done if 
active committers would have issues with Github.


+1.

I've always found the fight about “must be git” to be really tedious. Github 
supports both git and svn to this day, and people are free to use what they 
prefer by using the interface they are most familiar with.

While Github is popular today, this is only because the goals of the owners of 
Github are presently aligned with our goals. As Twitter has taught us, goals 
change at any time and without warning.


Hi Graham -- it's a little unclear to me where this would put you
"vote" wise about moving to read/write Git.

Anyone else with a stake have an opinion? It has been since about 2019
since we last discussed it here, I am hoping people have warmed up to
it.


I am +1 on moving. I do not have any particular love for git or svn on 
their own, and I realize that the proposed change does make outside 
contributions and certain workflows easier.

Re: [httpd-site] branch main updated: publishing release httpd-2.4.55

[Daniel Gruno]

On 2023-01-17 18:59, Eric Covener wrote:

Something is still subtly wrong here, the 2.4.55 section only has 1
entry instead of 3.
Will chat about it on #httpd on ASF slack.


We have addressed the immediate issue, and the page is rendering as 
intended, but we'll have to talk to the folks in charge of the cve 
process about the proper schema here, as ours may be a bit ... off.


TBD



On Tue, Jan 17, 2023 at 12:17 PM Daniel Gruno  wrote:


I have patched the system to deal with the inconsistencies, but those
should really be looked at. There seems to be a mix of "timeline"
entries that are not consistent throughout the dir (even when accounting
for v4.0 vs v5.0 CVE data), and those were throwing spanners into the
build process.

The CVE page should be back now, however.

On 2023-01-17 17:46, Eric Covener wrote:

Humbedooh is helping.

Note that the SVN repo is dead content, real content is in
g...@github.com:/apache/httpd-site

On Tue, Jan 17, 2023 at 11:39 AM Eric Covener  wrote:


I think it's 
https://svn.apache.org/repos/asf/httpd/site/trunk/content/security/cvejsontohtml.py
it hasn't been updated for the V5 JSON format, I misinterpreted Mark's mail.

I will try to make it tolerant of both.

On Tue, Jan 17, 2023 at 11:29 AM Ruediger Pluem  wrote:




On 1/17/23 5:16 PM, cove...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

covener pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/httpd-site.git


The following commit(s) were added to refs/heads/main by this push:
   new 83e7062  publishing release httpd-2.4.55
83e7062 is described below

commit 83e7062476d4a912f20ab275137b9587d441fdf0
Author: Eric Covener 
AuthorDate: Tue Jan 17 11:16:01 2023 -0500

  publishing release httpd-2.4.55
---
   content/doap.rdf  |   4 +-
   content/download.md   |  24 +++
   content/index.md  |   6 +-
   content/security/json/CVE-2006-20001.json | 110 
++
   content/security/json/CVE-2022-36760.json | 103 
   content/security/json/CVE-2022-37436.json |  88 


Looks like something went wrong as 
https://httpd.apache.org/security/vulnerabilities_24.html now results in a 404.

Regards

Rüdiger




--
Eric Covener
cove...@gmail.com

Re: [httpd-site] branch main updated: publishing release httpd-2.4.55

[Daniel Gruno]

I have patched the system to deal with the inconsistencies, but those 
should really be looked at. There seems to be a mix of "timeline" 
entries that are not consistent throughout the dir (even when accounting 
for v4.0 vs v5.0 CVE data), and those were throwing spanners into the 
build process.


The CVE page should be back now, however.

On 2023-01-17 17:46, Eric Covener wrote:

Humbedooh is helping.

Note that the SVN repo is dead content, real content is in
g...@github.com:/apache/httpd-site

On Tue, Jan 17, 2023 at 11:39 AM Eric Covener  wrote:


I think it's 
https://svn.apache.org/repos/asf/httpd/site/trunk/content/security/cvejsontohtml.py
it hasn't been updated for the V5 JSON format, I misinterpreted Mark's mail.

I will try to make it tolerant of both.

On Tue, Jan 17, 2023 at 11:29 AM Ruediger Pluem  wrote:




On 1/17/23 5:16 PM, cove...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

covener pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/httpd-site.git


The following commit(s) were added to refs/heads/main by this push:
  new 83e7062  publishing release httpd-2.4.55
83e7062 is described below

commit 83e7062476d4a912f20ab275137b9587d441fdf0
Author: Eric Covener 
AuthorDate: Tue Jan 17 11:16:01 2023 -0500

 publishing release httpd-2.4.55
---
  content/doap.rdf  |   4 +-
  content/download.md   |  24 +++
  content/index.md  |   6 +-
  content/security/json/CVE-2006-20001.json | 110 ++
  content/security/json/CVE-2022-36760.json | 103 
  content/security/json/CVE-2022-37436.json |  88 


Looks like something went wrong as 
https://httpd.apache.org/security/vulnerabilities_24.html now results in a 404.

Regards

Rüdiger




--
Eric Covener
cove...@gmail.com

Re: [VOTE] Release httpd-2.4.53-rc2 as httpd-2.4.53

[Daniel Gruno]

On 11/03/2022 13.14, Stefan Eissing wrote:

While the 72 hours have not all passed yet, the votes so far are positive.


72 hours is a guideline, not a hard rule. If you wanna do it in 48 or 
24, that's fine as long as there's a valid reason.




Given that no -1 vote will come, I call for a vote on the release time:

[ ] +1: release it later today, it needs to get out!
[ ] +0: do not really care
[ ] -1: better do it Monday, Admins have a life, too, you know?




Am 09.03.2022 um 17:19 schrieb Stefan Eissing :

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.53-rc2 as 2.4.53:
[ ] +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: 7a045e8e653aaf931f9667f3a7e1943bd81306bf908f316465f737a854d10c16 
*httpd-2.4.53-rc2.tar.gz
sha512: 
2fa1918aa44eb9984c0a294f416102088ed6874213391acd8c434b062603eb2a9ec64f7b1a218d4fe283d74fc9956650297d0b4dda57dcd8533b075a7321ec78
 *httpd-2.4.53-rc2.tar.gz

The SVN candidate source is found at tags/2.4.53-rc2-candidate.

Kind Regards,
Stefan

Re: Remove link to "complete list of mirrors" from download page

[Daniel Gruno]

I've culled what is no longer relevant here.

With regards,
Daniel.

On 22/01/2022 19.37, Daniel Sahlberg wrote:

Hi,

Due to ASF's migration to the new Download Content Delivery System, the 
"complete list of mirrors" ([1]) no longer exists om www.apache.org.


Can someone with commit access update the download script (I'm assuming 
it would actually be download.mdtext) and remove this link?


Do note that the download script provided by ASF is, depending on your 
location, adding the https://dlcdn.apache.org both to the [http] and to 
the [backup] lists and thus, for some users, the Other mirrors display 
the same site as both the primary and the backup download site. I have 
tried to work around this but didn't manage (see for example [3]). I'm 
not sure if Infra consider it to be a bug that dlcdn is in both lists [4].


Kind regards,

Daniel Sahlberg

(Hangaround in the Subversion project).


[1] https://www.apache.org/mirrors/

[2] https://httpd.apache.org/download.cgi

[3] https://lists.apache.org/thread/0hrtsyc1bj7nv8qqj8jl0gnn49l0fhwz

[4] https://lists.apache.org/thread/ws49tpb8dqzpk2652qsf4ndwoq5y5v3c 
(require authentication)

Re: Download page appears to be broken

[Daniel Gruno]

On 31/10/2021 19.11, Craig Russell wrote:

Hi,

I'm looking at the download page https://httpd.apache.org/download


It's https://httpd.apache.org/download.cgi - the other page is the template.



I tried the link  httpd-2.4.51.tar.bz2 
https://httpd.apache.org/%5Bpreferred%5D/httpd/httpd-2.4.51.tar.bz2
but it gives me a 404.

This may be due to the recent change to use dldcn instead of mirrors...

Or my browser might be acting up.

Best regards,
Craig

Craig L Russell
c...@apache.org

Re: sending announcement mail

[Daniel Gruno]

it's on announce@httpd.a.o already. I modded it through.

You need to send it to annou...@apache.org as well.

On 16/09/2021 06.03, ste...@eissing.org wrote:




Am 16.09.2021 um 12:40 schrieb Greg Stein :

Fails, how? ... email to annou...@apache.org needs to come from your 
@apache.org account and include a Reply-To. The moderators may have bounced 
your message, if it didn't include some key aspects (eg. download links, where 
to find KEYs, etc)


Yes, exactly. It did not fail on send, it did just not appear and Mark Thomas 
as moderator of announce@a.o did not see it. But now it appeared and I did a 
retry on the announce@httpd.a.o a minute ago.

Maybe my initial attempts triggered some spammer detected and blackholed the 
correct mails afterwards. Or there was a queue stuck somewhere. I cannot tell 
and thus I opened a ticket at infra 
https://issues.apache.org/jira/browse/INFRA-22338.

Cheers,
Stefan



Cheers,
-g


On Thu, Sep 16, 2021 at 4:26 AM ste...@eissing.org  wrote:
...is failing for me. The method from the old announce.sh script
does not give any error on curl upload, but no mail appears.

Anyone got a suggestion?

- Stefan

Re: disallow HTTP 0.9 by default?

[Daniel Gruno]

On 22/07/2021 10.02, Ruediger Pluem wrote:



On 7/21/21 10:04 PM, Eric Covener wrote:

I was chasing an unrelated thread about close_notify alerts and
reminded me -- is it time to change the default for
HttpProtocolOptions from Allow0.9 to Require1.0?

As the manual says, the requirement was dropped in RFC 7230. It seems
like the kind of potential gadget in future desynch/smuggling kind of
attacks that shouldn't be on by default today.


+1 for Require1.0 on 2.4. Typically I would not agree because it can break 
existing applications, but are there really setups out
there that work with HTTP 0.9? I don't believe so. Hence my +1.


In which case one can just manually switch back to Allow0.9, right? :)

+1 for Require1.0



Regards

Rüdiger

Re: migration of the HTTPD project website

[Daniel Gruno]

On 16/07/2021 22.45, Christophe JAILLET wrote:

Hi,
when a PULL request is generated, it is forwarded to @dev. Same when it 
is accepted.

This is just fine for me.

However, when one directly modify within apache/httpd-site on GitHub, 
apparently, no notification is sent.


I think that is would be useful to also have these changes sent 
somewhere so that others know that there is some activity (and 
potentially fix/improve things, should it be only typo)


Is it possible?
Do you share this point of view?


Yeah, this was actually added by Dave already, but not applied due to a 
timing issue. I've prodded the .asf.yaml file now, and things should be 
good.




CJ


Regards,
Dave



Regards

Rüdiger

Re: migration of the HTTPD project website

[Daniel Gruno]

On 07/07/2021 14.14, Eric Covener wrote:

https://bz.apache.org/bugzilla/show_bug.cgi?id=65439

whoops, looks like the manual links from for the following are not working:

https://httpd.apache.org/mod_ftp/
https://httpd.apache.org/mod_cgid/

Daniel, do you recall how this worked before? Maybe we lost some of
this extra content when you moved where httpd.apache.org points?


I know where it originally pointed too, and I'll try to weave that into 
the new site checkout. Should apply within 30 minutes.





On Mon, Jul 5, 2021 at 4:15 AM Yann Ylavic  wrote:


On Mon, Jul 5, 2021 at 9:56 AM Ruediger Pluem  wrote:


I don't think that we want to release them. I am fine with omitting trunk from 
the path. Anyone objected to

svn mv https://svn.apache.org/repos/asf/httpd/site/trunk/tools 
https://svn.apache.org/repos/asf/httpd/dev-tools/

?


+1

Regards;
Yann.




--
Eric Covener
cove...@gmail.com

Re: Security features of Github

[Daniel Gruno]

On 25/06/2021 09.23, Ruediger Pluem wrote:

I would like to leverage the "security features" of GitHub like Dependabot 
alerts and Code scanning alerts.

First question: Do we want this? Does anyone object?

Second question: Is this possible with our GitHub setup? I known that this 
question might be better suited for the infra list, but
OTOH I know that some infra guys are here as well.
While Dependabot seems to be only a matter of activating which might be easy I 
understand that The Code scanning alerts run as
GitHub actions and I am not sure if we can use GitHub actions or what the 
limits are as for the CI stuff we use Travis.

Regards

Rüdiger



Dependabot unfortunately is not a viable option, as that would start 
leaking potential issues into public space due to how our and their 
infra works.

Re: migration of the HTTPD project website

[Daniel Gruno]

On 18/06/2021 14.33, Eric Covener wrote:

On Fri, Jun 18, 2021 at 8:20 AM Daniel Gruno  wrote:


On 18/06/2021 14.16, Eric Covener wrote:

I reviewed Christophes old post, I think we should proceed with the
ASF template and migration process. Worst case Christophe can still
apply what he has learned to further refine the output of the
migration.

I'll create an infra ticket to ask for the repo and migration on
Monday unless someone objects.


repo request is done via selfserve.apache.org


Since we do not use gitbox yet: So this would result in e.g.
github.com/apache/httpd-site and users can then choose to interact
with github or gitbox.a.o, right?


Yep.




migrating the site (and using pelican/jbake/hugo??) is done also
self-serve-y via .asf.yaml - s.apache.org/asfyaml


A lot of info there, I see the pelican config stuff but can you give a
hint about the migration aspect there?



The migration would largely just happen automatically once .asf.yaml is 
in place and working. There is some httpd docs aliasing that infra needs 
to figure out, but that's tangential to this.

Re: migration of the HTTPD project website

[Daniel Gruno]

On 18/06/2021 14.16, Eric Covener wrote:

I reviewed Christophes old post, I think we should proceed with the
ASF template and migration process. Worst case Christophe can still
apply what he has learned to further refine the output of the
migration.

I'll create an infra ticket to ask for the repo and migration on
Monday unless someone objects.


repo request is done via selfserve.apache.org
migrating the site (and using pelican/jbake/hugo??) is done also 
self-serve-y via .asf.yaml - s.apache.org/asfyaml





On Thu, Jun 17, 2021 at 9:34 AM Andrew Wetmore  wrote:


To avoid confusion because of the bad title for my previous email, here is what 
I wrote concerning your project website:

The Apache CMS system is going out of service and we really need to get the
last couple of projects off it.

I know that Christophe was working on a migration path to Pelican some
months ago, so perhaps all is well. If not, we now have an "ASF-Pelican"
template and migration process available that could speed things along.

Please let me know today where things stand with your website. Information
about the Pelican template is at https://infra.apache.org/asf-pelican.html.

(please do a reply-all, as I am not subscribed to your dev@ list.)

Thank you!

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




--
Eric Covener
cove...@gmail.com

Re: libcurl dependency version fix for mod_md

[Daniel Gruno]

On 15/10/2020 15.50, Stefan Eissing wrote:




Am 15.10.2020 um 15:28 schrieb Alexander Gerasimov 
:

Dear httpd devs,

Please apply a small patch that fixes a minimal curl version (so mod_md can be 
built on CentOS 7).

I made a pull request https://github.com/apache/httpd/pull/108/ and filed a 
bugzilla bug with a patch, but there was no reply for 6 months.


Sorry to hear that. Alas, the httpd github repro is a readonly mirror of our 
subversion repository and not monitored for PRs. Which we should do.


It wasn't monitored six months ago, but it is now (as of two months ago 
I think), at notificati...@httpd.apache.org - people are encouraged to 
join that list and help out :)




I brought your change into the subversion repository and also on my actively 
maintained mod_md repository at . If you ever 
want to bring another PR to the module, that is a good place.

Thanks a lot,

Stefan



Thanks a lot.


Best regards,
Alexander Gerasimov
Chief Technical Officer
CodeIT LLC

M: +380 68 891 17 99
S: codeguard
E: alexander.gerasi...@codeit.pro
W: codeit.pro

Re: Your project's website

[Daniel Gruno]

On 05/08/2020 14.17, Andrew Wetmore 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!


We do use it, and it *should* be trivial for us to switch to something 
like pelican instead, for the main site (docs are another thing 
entirely). While I'll be happy to assist with that, I don't want to put 
on too many hats here, so if someone would volunteer to be the liaison, 
that would be wonderful.


With regards,
Daniel.






[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 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Can github activity (new PRs, comments) be forwarded to dev@ ?

[Daniel Gruno]

On 29/04/2020 10.52, Daniel Gruno wrote:

On 29/04/2020 10.22, Daniel Gruno wrote:




I recommend using selfserve.apache.org <http://selfserve.apache.org> 
to create notifications@httpd (the typical name/pattern for this 
stuff), then to use .asf.yaml to sort out the various emails.


Once we are in agreement on a name here, I can get this processed with 
my VP hat on, and task infra to figure out how to relay notifications 
there :)


Going to JFDI here... notifications@httpd coming right up :p


And done, plus we have GH notifications going there now :)







Cheers,
-g

Re: Can github activity (new PRs, comments) be forwarded to dev@ ?

[Daniel Gruno]

On 29/04/2020 10.22, Daniel Gruno wrote:




I recommend using selfserve.apache.org <http://selfserve.apache.org> 
to create notifications@httpd (the typical name/pattern for this 
stuff), then to use .asf.yaml to sort out the various emails.


Once we are in agreement on a name here, I can get this processed with 
my VP hat on, and task infra to figure out how to relay notifications 
there :)


Going to JFDI here... notifications@httpd coming right up :p





Cheers,
-g

Re: Can github activity (new PRs, comments) be forwarded to dev@ ?

[Daniel Gruno]

On 29/04/2020 10.11, Greg Stein wrote:
On Wed, Apr 29, 2020 at 8:19 AM Joe Orton > wrote:


On Tue, Apr 28, 2020 at 05:19:09PM +0200, Ruediger Pluem wrote:
 > +1 g...@httpd.apache.org  (I declare
the naming discussion for the list name opened :-)).
 > This offers an easy opt-in for those who are interested in these
updates.

+1 from me, does anybody know if it's actually technically possible to
do though?  AFAICT there is not github project setting to do this kind
of thing specifically so we'd either need to use the API somehow?  Or
add whate...@httpd.apache.org  to
a personal github account and have
notifications through that, which seems ugly.


Solved.
https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Notificationsettingsforrepositories 



This unfortunately won't work since httpd.git is a mirror repository.
I'm sure we can solve the PR notifications one way or the other, but it 
can't be done through .asf.yaml until such a point where httpd is using 
git as its main VCS.




I recommend using selfserve.apache.org  to 
create notifications@httpd (the typical name/pattern for this stuff), 
then to use .asf.yaml to sort out the various emails.


Once we are in agreement on a name here, I can get this processed with 
my VP hat on, and task infra to figure out how to relay notifications 
there :)




Cheers,
-g

Countdown to 25 years - has httpd changed your life?

[Daniel Gruno]

Hi wonderful apache people!

As we count down to the 25th anniversary of the Apache Group, founded 
February 27th 1995 (first release of the apache webserver was in April 
1995), I'd like to put some extra effort into the quarterly board report 
I, as chair of the project, have to present to the board of directors at 
the Apache Software Foundation in February.


So I thought to myself, it would be fun to get some testimonials to 
showcase how this project has survived, grown, and remained in the top 
for 25 years, helping people achieve their goals and in the process 
helping people grow. Personally, I would not be where I am today without 
this project - I owe so much to it, and it has helped me reach many a goal.


If you too have been affected by httpd, or if you just think this is a 
really nifty piece of software because it helps you do X, Y or Z, please 
let us know on this thread. I'll later collate the responses, shorten 
them a tad, and compile a shortened list of testimonials for the board 
report.


You can tell us about your experience with the product (httpd), the 
project (the apache http server project), or just your interactions with 
the people involved. Please keep it concise, as we wouldn't want to 
force the board to go through 150 pages :)


With very warm regards,
Daniel.

Ignore the GitHub email...

[Daniel Gruno]

That was me trying to get travis notifications working...

Re: Travis CI failures

[Daniel Gruno]

On 08/12/2019 20.12, Luca Toscano wrote:

Il giorno dom 1 dic 2019 alle ore 12:05 Luca Toscano
 ha scritto:


Travis seems not able to deliver emails to dev@, I opened a jira to
Infra: https://issues.apache.org/jira/browse/INFRA-19508


It was suggested to ask a moderator of httpd-dev@ to approve one of
the Travis emails as way to fix this issue. I am not aware of who is a
moderator, but if anybody is I'd ask to follow up when possible :)

Thanks in advance,

Luca



Looks like dev@httpd has to be verified somehow...I'll see what I can find.

Re: modify bugzilla resolved statuses?

[Daniel Gruno]

On 12/11/2019 13.57, Eric Covener wrote:

On Tue, Nov 12, 2019 at 7:47 AM Daniel Gruno  wrote:


On 12/11/2019 13.29, Eric Covener wrote:

Is there a way to add new sub-statuses under Resolved in our bugzilla?

It would be nice to have something kind of neutral for things that are
essentially answered questions rather than "invalid" or
"worksforsome".  I think "invalid" is kind of impolite and invites
argumentation.



Yes, how about 'INFORMATIONPROVIDED' ?


That helps, or even "CLOSED"



Added both for good measure :)

Re: modify bugzilla resolved statuses?

[Daniel Gruno]

On 12/11/2019 13.29, Eric Covener wrote:

Is there a way to add new sub-statuses under Resolved in our bugzilla?

It would be nice to have something kind of neutral for things that are
essentially answered questions rather than "invalid" or
"worksforsome".  I think "invalid" is kind of impolite and invites
argumentation.



Yes, how about 'INFORMATIONPROVIDED' ?

Re: Migrate to git?

[Daniel Gruno]

On 14/10/2019 09.51, Stefan Sperling wrote:

On Mon, Oct 14, 2019 at 03:27:31PM +0100, Joe Orton wrote:

At the moment I think we have a quality control problem for 2.4.x, yet I
find it hard to justify spending much time on writing test cases because
that stuff is run so rarely.  How many tests proposed in 2.4.x STATUS
have had a full test suite run?  I certainly don't always do it.  But if
we get the tests running all the time automatically it's much easier to
see a return on investment for improving test coverage.


I see there's already a buildbot job for httpd trunk:
https://ci.apache.org/waterfall?tag=httpd-trunk
It seems this build job is configured to run a compile but it does not
run the test suite? Putting Github/Travis questions aside, an easy way
to get automated tests going with minimal effort today could be to run
the existing tests inside httpd's existing buildbot job.


Infra is in the midst of setting up a new buildbot 2 service with 
automated builds sort of like what travis does. It's not ready for prime 
time just yet, but within a month or so, we should be able to directly 
configure and trigger dynamic builds/tests via a yaml file in our repo.




The Subversion project has been doing this for years.
See https://subversion.apache.org/buildbot/all

Re: Migrate to git?

[Daniel Gruno]

On 07/10/2019 14.48, Ruediger Pluem wrote:



On 10/06/2019 06:51 PM, Roy T. Fielding wrote:

On Oct 5, 2019, at 1:09 PM, Jim Jagielski  wrote:

Various PMCs have made their default/de-facto SCM git and have seen an increase 
in contributions and contributors...

Is this something the httpd project should consider? Especially w/ the 
foundation officially supporting Github, it seems like time to have a 
discussion about it, especially as we start thinking about the next 25 years of 
this project :)


I don't like git. I don't like isolating work on branches. If we want to work 
on it as a base,
we need to agree on how to manage the release branches first and their names 
(so that
the existing history can be merged accordingly).

I hate our existing bugzilla blackhole and manual process of PRs.

I do like Github. I like the flexibility and openness of Github issues and 
tracking with commits.
I like the PRs and review mechanisms.  I am not sure what to do about security 
issues.


Working on other projects recently I was impressed how much of the contribution 
legwork
that we do manually today can be done by Github processes and I was impressed by
the review process possibilities via PR.
This is a big plus over how we have to handle contributions today.
But this also means we can only really benefit if we fully leverage PR and GH 
issues for our workflows.

Apart from Github I still like Subversion more than git, especially the lean 
working copies and the immutable
history.


I don't know how to handle folks who don't have Github IDs already (or don't 
want them).

Currently, I am +0 on the idea, but +1 if the way forward is worked out and the 
process
of migrating history is extensively automated/tested first.  I did that for 
httpwg and it was
a pain in the ass even with only five committers.  But it can be done.


Did I get it correct from Daniel, that this issue is already solved?
But looking at one of my recent Subversion commits (r1866078 / 
cb8c40c581d17382cba338b3d90c67b914648984)
that happened after I joined the Apache Org on Github does not show my Github 
user as committer
(it only mentions my full name, so there is some connection).


To me, when I look at the commit[1], it links to your github account[2] 
if you click on the user avatar.



@Daniel: Is this the issue to be fixed on Oct 12th?
All in all I am currently +0.


What is being fixed on october 12th is the live sync of the git mirror 
after the catastrophic data center failure we had in september[3].



[1] 
https://github.com/apache/httpd/commit/cb8c40c581d17382cba338b3d90c67b914648984

[2] https://github.com/rpluem
[3] https://blogs.apache.org/infra/entry/subversion-to-git-service-git

Re: Migrate to git?

[Daniel Gruno]

On 06/10/2019 17.59, Nick Kew wrote:



On 6 Oct 2019, at 04:06, Daniel Gruno  wrote:

On 05/10/2019 19.30, Nick Kew wrote:



If it moves to github, how and at what level is history preserved? Github can do
alarming things with history even for a project that's always been there!


We would have the exact same level of history as before (one might even say 
we'll get more history, as you can specify committer and author separately in 
git). If you look at https://github.com/apache/httpd which is our current git 
mirror, it should have the exact same commits going back to 1996 as the 
subversion repository. There is a bit of a lag on the mirror right now, but 
that is a separate issue that will be fixed on October 12th.


OK, I've just dug up an example in an Apache/Github project.  A simple renaming
of a source file, that with "svn mv" would have preserved history, seems to have
essentially wiped its past.  'History' is highly misleading, 'Blame' is 100% 
wrong!


It would be 100% wrong in svn as well if the same operation had been 
performed there, as it wasn't a move - the number of lines don't match 
up. There is a `git mv` just like `svn mv` that preserves history, AIUI. 
A file where `svn mv` was actually used [1] shows that the history is 
preserved through the mv operation and blame works as intended, even in git.




https://github.com/apache/trafficserver/blob/master/plugins/experimental/stream_editor/stream_editor.cc

And that's within git: no actual change-of-repos involved.

Regarding httpd, we have the git mirror, so access is available through whatever
a contributor prefers.  How is that not best-of-both-worlds?



As Eric alluded to, it's much less about svn versus git than it is about 
tapping into the community on GitHub. If there was an svnhub, I'd be all 
for that as an easier way to do this, but alas no.


[1] 
https://github.com/apache/httpd/blame/dc8ed8a7df9edbe9340a1bc5f01501dbd60e8366/server/mpm/beos/config5.m4

Re: Migrate to git?

[Daniel Gruno]

On 05/10/2019 19.30, Nick Kew wrote:




On 5 Oct 2019, at 21:09, Jim Jagielski  wrote:

Various PMCs have made their default/de-facto SCM git and have seen an increase 
in contributions and contributors...

Is this something the httpd project should consider? Especially w/ the 
foundation officially supporting Github, it seems like time to have a 
discussion about it, especially as we start thinking about the next 25 years of 
this project :)

Cheers!


[apologies if this appears twice.  Just sent with wrong from: address so I 
expect
apache to bounce it.  I'm still on limited 'net connectivity since my house 
move -
ISP due on Oct 14th to install proper connection].

If it moves to github, how and at what level is history preserved? Github can do
alarming things with history even for a project that's always been there!


We would have the exact same level of history as before (one might even 
say we'll get more history, as you can specify committer and author 
separately in git). If you look at https://github.com/apache/httpd which 
is our current git mirror, it should have the exact same commits going 
back to 1996 as the subversion repository. There is a bit of a lag on 
the mirror right now, but that is a separate issue that will be fixed on 
October 12th.


There is also, as you mention, the risk of force-pushing to rewrite 
history, but as I understand it, we can disable this by requiring PRs 
for each change to the canonical branch(es).


The old subversion history would also be retained on the svn master.



Don't we have an svn-git gateway?  If that's not best-of-both-worlds, why not?

Re: Migrate to git?

[Daniel Gruno]

On 05/10/2019 15.09, Jim Jagielski wrote:

Various PMCs have made their default/de-facto SCM git and have seen an increase 
in contributions and contributors...

Is this something the httpd project should consider? Especially w/ the 
foundation officially supporting Github, it seems like time to have a 
discussion about it, especially as we start thinking about the next 25 years of 
this project :)

Cheers!



I'd be quite okay with this move - it was IIRC proposed a year or two 
ago as well, but didn't gain much traction.


On a related note (sorry for the segue), we should probably also look at 
the web site repo, perhaps split that into a separate git repo if we do 
make the move, as the CMS system will go away at some point.

Re: [VOTE] Release httpd-2.4.41

[Daniel Gruno]

+1 From me as well.
A few snags with lua, but that's very platform specific and doesn't 
affect the vote. I should probably look into better compat with 5.3 later :)



On 8/9/19 11:25 PM, Daniel Ruggeri wrote:



On 2019/08/09 13:40:38, Daniel Ruggeri  wrote:

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.41:
[ ] +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:
sha1: b713e835aa7cde823a4b7f8e3463164f3d9fe63e *httpd-2.4.41.tar.gz
sha256: 3c0f9663240beb0f008acf3b4501c4f339d7467ee345a36c86c46b4d6f3a5461  
*httpd-2.4.41.tar.gz
--
Daniel Ruggeri


+1 from me.

Tested under the following conditions...

system:
   kernel:
 name: Linux
 release: 4.9.0-8-amd64
 version: #1 SMP Debian 4.9.144-3 (2019-02-02)
 machine: x86_64

   libraries:
 openssl: "1.1.1c"
 openldap: "2.4.48"
 apr: "1.7.0"
 apr-util: "1.6.1"
 iconv: "1.2.2"
 brotli: "1.0.7"
 nghttp2: "1.39.1"
 zlib: "1.2.11"
 pcre: "8.43"
 libxml2: "2.9.9"
 php: "7.3.8"
 lua: "5.3.5"
 curl: "7.65.3"

[COMPLETED] Migrating our wiki

[Daniel Gruno]

Our wiki was successfully transferred to the confluence service, and is 
available at: https://cwiki.apache.org/confluence/display/HTTPD


All httpd committers should have write access to it, and I'll look into 
how we lock down the old wiki.


With regards,
Daniel.

On 21/05/2019 13.13, Dennis Clarke wrote:

On 5/21/19 1:00 PM, Daniel Gruno wrote:

On 21/05/2019 12.51, Dennis Clarke wrote:

On 5/21/19 12:32 PM, Daniel Gruno wrote:

Hi folks,
looks like we have to migrate our moin wiki to confluence in the 
coming weeks. Unless there are objections, I'll file a self-serve 
request to start migration tomorrow, and within a day or two, we 
should have it all moved to confluence, with LDAP permissions for us.


Does this imply that jira is used for task tracking also?  That usually
travels hand in hand with confluence.



We do not have any current plans to migrate from bugzilla.



Thank you for that !  As much as I love jira for tasks and projects it
is over kill for bug tracking.

dc

Re: Migrating our wiki

[Daniel Gruno]

On 21/05/2019 12.51, Dennis Clarke wrote:

On 5/21/19 12:32 PM, Daniel Gruno wrote:

Hi folks,
looks like we have to migrate our moin wiki to confluence in the 
coming weeks. Unless there are objections, I'll file a self-serve 
request to start migration tomorrow, and within a day or two, we 
should have it all moved to confluence, with LDAP permissions for us.


Does this imply that jira is used for task tracking also?  That usually
travels hand in hand with confluence.



We do not have any current plans to migrate from bugzilla.

Migrating our wiki

[Daniel Gruno]

Hi folks,
looks like we have to migrate our moin wiki to confluence in the coming 
weeks. Unless there are objections, I'll file a self-serve request to 
start migration tomorrow, and within a day or two, we should have it all 
moved to confluence, with LDAP permissions for us.

[NOTICE] This list is closing

[Daniel Gruno]

Hello, apreq-dev people.
As this list has been more or less weaved into dev@httpd, and as there has been 
virtually no traffic over the past few years, we are now closing this list. 
People wishing to discuss apreq and co, can do so on the d...@httpd.apache.org 
list as always.

This list will close within the next week.

With regards,
Daniel on behalf of the HTTP Server project.

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

[Daniel Gruno]

On 1/22/19 8:13 PM, Daniel Ruggeri wrote:

On 2019-01-22 11:39, Daniel Gruno wrote:

On 1/22/19 6:08 PM, Daniel Ruggeri wrote:

Hi, Cristophe;
    Thanks for the extra eye. Fortunately, this is expected behavior. 
Since the announcement goes out on some future date, the date is 
fixed up later in the announce.sh script.




Daniel, could you please make sure to add a Date: header to the
announcement emails that are sent out, so we don't have to rely on the
archives guessing the date? :) And, if possible, a Message-ID header
as well.

With regards,
other Daniel.


Hi, Daniel;
    No problem. Added in r1851853! I assume it's desirable to use the 
same Date and Message-ID headers for messages sent to different 
recipients (but with the same contents/subject/etc). This should 
facilitate correlating replies... but I'm not sure if it's technically 
"correct" to do.




Our archives don't really care, as they add the mailing list ID as part 
of the internal message id. Generally, if it's the same email but you 
have multiple To: lines in it, it's fine to have the same ID.

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

[Daniel Gruno]

On 1/22/19 6:08 PM, Daniel Ruggeri wrote:

Hi, Cristophe;
    Thanks for the extra eye. Fortunately, this is expected behavior. 
Since the announcement goes out on some future date, the date is fixed 
up later in the announce.sh script.




Daniel, could you please make sure to add a Date: header to the 
announcement emails that are sent out, so we don't have to rely on the 
archives guessing the date? :) And, if possible, a Message-ID header as 
well.


With regards,
other Daniel.

Re: Apache 0-day / apache-uaf / use after free bugs

[Daniel Gruno]

On 1/22/19 8:09 AM, Stefan Priebe - Profihost AG wrote:

Hi,

in twitter and other social media channels they're talking about a
current apache 0 day:
https://twitter.com/i/web/status/1087593706444730369

which wasn't handled / isn't currently fixed.

Some details are here:
https://github.com/hannob/apache-uaf

If this is true there will be exploits soon. Is there anything planned?
Does 2.4.38 fix those issues?

Greets,
Stefan



Hi Stefan, and good morning.

I figured I should write something to calm people that might be concerned.

I will reply in length in a while (coffee is needed first), it takes 
time to write a proper response that explains our processes and 
considerations with issues like this, especially when people start 
hyping the matter. Such is social media, I guess.


Until then, I will say quickly that we do not at present consider this 
something you should be alarmed about. Boring elaboration to follow in a 
while when I have compiled it :)


With regards,
Daniel, speaking as just a normal committer.

Re: [VOTE] Release httpd-2.4.28

[Daniel Gruno]

On 1/17/19 6:59 PM, Jim Jagielski wrote:

Ahhh good.


On Jan 17, 2019, at 12:46 PM, Yann Ylavic  wrote:

On Thu, Jan 17, 2019 at 6:44 PM Jim Jagielski  wrote:


Note that simply changing the commit msg logs does not solve the problem. There 
is,
in fact, no 2.4.38 tag at all. And I'm guessing we destroyed the "real" 2.4.28 
tag... :(


Fortunately it just created tags/2.4.28/2.4.x since tags/2.4.28 existed already.




It's subversion, not git - we can always revert ;p

Re: Changing mod_lua to stable

[Daniel Gruno]

On 12/17/18 8:23 PM, Daniel Gruno wrote:

Hi folks,
I've been pondering on the state of mod_lua, and it seems like it's time 
to get rid of the 'experimental' note, which still scares off a lot of 
people. The API has been steady over the past few years, I believe, and 
the code itself seems to be in a stable state, so I'm inclined to go 
ahead and get it moved over to stable, including switching from CTR to RTC.


I think a lazy 72h consensus should do nicely here, WDYT?


I should probably add that we've been using it at the ASF for years now, 
in production, with very few issues related to the actual module (and 
then a bunch related to us making terrible lua scripts :p)




With regards,
Daniel.

Changing mod_lua to stable

[Daniel Gruno]

Hi folks,
I've been pondering on the state of mod_lua, and it seems like it's time 
to get rid of the 'experimental' note, which still scares off a lot of 
people. The API has been steady over the past few years, I believe, and 
the code itself seems to be in a stable state, so I'm inclined to go 
ahead and get it moved over to stable, including switching from CTR to RTC.


I think a lazy 72h consensus should do nicely here, WDYT?

With regards,
Daniel.

[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Daniel Gruno]

[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
 DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]

Hello Apache projects,

I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
months. All repositories will be moved to the new gitbox service which
includes direct write access on github as well as the standard ASF
commit access via gitbox.apache.org.

## Why this move? ##
The move comes as a result of retiring the git-wip service, as the
hardware it runs on is longing for retirement. In lieu of this, we
have decided to consolidate the two services (git-wip and gitbox), to
ease the management of our repository systems and future-proof the
underlying hardware. The move is fully automated, and ideally, nothing
will change in your workflow other than added features and access to
GitHub.

## Timeframe for relocation ##
Initially, we are asking that projects voluntarily request to move
their repositories to gitbox, hence this email. The voluntary
timeframe is between now and January 9th 2019, during which projects
are free to either move over to gitbox or stay put on git-wip. After
this phase, we will be requiring the remaining projects to move within
one month, after which we will move the remaining projects over.

To have your project moved in this initial phase, you will need:

- Consensus in the project (documented via the mailing list)
- File a JIRA ticket with INFRA to voluntarily move your project repos
  over to gitbox (as stated, this is highly automated and will take
  between a minute and an hour, depending on the size and number of
  your repositories)

To sum up the preliminary timeline;

- December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
  relocation
- January 9th -> February 6th: Mandated (coordinated) relocation
- February 7th: All remaining repositories are mass migrated.

This timeline may change to accommodate various scenarios.

## Using GitHub with ASF repositories ##
When your project has moved, you are free to use either the ASF
repository system (gitbox.apache.org) OR GitHub for your development
and code pushes. To be able to use GitHub, please follow the primer
at: https://reference.apache.org/committer/github


We appreciate your understanding of this issue, and hope that your
project can coordinate voluntarily moving your repositories in a
timely manner.

All settings, such as commit mail targets, issue linking, PR
notification schemes etc will automatically be migrated to gitbox as
well.

With regards, Daniel on behalf of ASF Infra.

PS:For inquiries, please reply to us...@infra.apache.org, not your 
project's dev list :-).

[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Daniel Gruno]

[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
 DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]

Hello Apache projects,

I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
months. All repositories will be moved to the new gitbox service which
includes direct write access on github as well as the standard ASF
commit access via gitbox.apache.org.

## Why this move? ##
The move comes as a result of retiring the git-wip service, as the
hardware it runs on is longing for retirement. In lieu of this, we
have decided to consolidate the two services (git-wip and gitbox), to
ease the management of our repository systems and future-proof the
underlying hardware. The move is fully automated, and ideally, nothing
will change in your workflow other than added features and access to
GitHub.

## Timeframe for relocation ##
Initially, we are asking that projects voluntarily request to move
their repositories to gitbox, hence this email. The voluntary
timeframe is between now and January 9th 2019, during which projects
are free to either move over to gitbox or stay put on git-wip. After
this phase, we will be requiring the remaining projects to move within
one month, after which we will move the remaining projects over.

To have your project moved in this initial phase, you will need:

- Consensus in the project (documented via the mailing list)
- File a JIRA ticket with INFRA to voluntarily move your project repos
  over to gitbox (as stated, this is highly automated and will take
  between a minute and an hour, depending on the size and number of
  your repositories)

To sum up the preliminary timeline;

- December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
  relocation
- January 9th -> February 6th: Mandated (coordinated) relocation
- February 7th: All remaining repositories are mass migrated.

This timeline may change to accommodate various scenarios.

## Using GitHub with ASF repositories ##
When your project has moved, you are free to use either the ASF
repository system (gitbox.apache.org) OR GitHub for your development
and code pushes. To be able to use GitHub, please follow the primer
at: https://reference.apache.org/committer/github


We appreciate your understanding of this issue, and hope that your
project can coordinate voluntarily moving your repositories in a
timely manner.

All settings, such as commit mail targets, issue linking, PR
notification schemes etc will automatically be migrated to gitbox as
well.

With regards, Daniel on behalf of ASF Infra.

PS:For inquiries, please reply to us...@infra.apache.org, not your 
project's dev list :-).

[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Daniel Gruno]

[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
 DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]

Hello Apache projects,

I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
months. All repositories will be moved to the new gitbox service which
includes direct write access on github as well as the standard ASF
commit access via gitbox.apache.org.

## Why this move? ##
The move comes as a result of retiring the git-wip service, as the
hardware it runs on is longing for retirement. In lieu of this, we
have decided to consolidate the two services (git-wip and gitbox), to
ease the management of our repository systems and future-proof the
underlying hardware. The move is fully automated, and ideally, nothing
will change in your workflow other than added features and access to
GitHub.

## Timeframe for relocation ##
Initially, we are asking that projects voluntarily request to move
their repositories to gitbox, hence this email. The voluntary
timeframe is between now and January 9th 2019, during which projects
are free to either move over to gitbox or stay put on git-wip. After
this phase, we will be requiring the remaining projects to move within
one month, after which we will move the remaining projects over.

To have your project moved in this initial phase, you will need:

- Consensus in the project (documented via the mailing list)
- File a JIRA ticket with INFRA to voluntarily move your project repos
  over to gitbox (as stated, this is highly automated and will take
  between a minute and an hour, depending on the size and number of
  your repositories)

To sum up the preliminary timeline;

- December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
  relocation
- January 9th -> February 6th: Mandated (coordinated) relocation
- February 7th: All remaining repositories are mass migrated.

This timeline may change to accommodate various scenarios.

## Using GitHub with ASF repositories ##
When your project has moved, you are free to use either the ASF
repository system (gitbox.apache.org) OR GitHub for your development
and code pushes. To be able to use GitHub, please follow the primer
at: https://reference.apache.org/committer/github


We appreciate your understanding of this issue, and hope that your
project can coordinate voluntarily moving your repositories in a
timely manner.

All settings, such as commit mail targets, issue linking, PR
notification schemes etc will automatically be migrated to gitbox as
well.

With regards, Daniel on behalf of ASF Infra.

PS:For inquiries, please reply to us...@infra.apache.org, not your 
project's dev list :-).

[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Daniel Gruno]

[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
 DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]

Hello Apache projects,

I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
months. All repositories will be moved to the new gitbox service which
includes direct write access on github as well as the standard ASF
commit access via gitbox.apache.org.

## Why this move? ##
The move comes as a result of retiring the git-wip service, as the
hardware it runs on is longing for retirement. In lieu of this, we
have decided to consolidate the two services (git-wip and gitbox), to
ease the management of our repository systems and future-proof the
underlying hardware. The move is fully automated, and ideally, nothing
will change in your workflow other than added features and access to
GitHub.

## Timeframe for relocation ##
Initially, we are asking that projects voluntarily request to move
their repositories to gitbox, hence this email. The voluntary
timeframe is between now and January 9th 2019, during which projects
are free to either move over to gitbox or stay put on git-wip. After
this phase, we will be requiring the remaining projects to move within
one month, after which we will move the remaining projects over.

To have your project moved in this initial phase, you will need:

- Consensus in the project (documented via the mailing list)
- File a JIRA ticket with INFRA to voluntarily move your project repos
  over to gitbox (as stated, this is highly automated and will take
  between a minute and an hour, depending on the size and number of
  your repositories)

To sum up the preliminary timeline;

- December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
  relocation
- January 9th -> February 6th: Mandated (coordinated) relocation
- February 7th: All remaining repositories are mass migrated.

This timeline may change to accommodate various scenarios.

## Using GitHub with ASF repositories ##
When your project has moved, you are free to use either the ASF
repository system (gitbox.apache.org) OR GitHub for your development
and code pushes. To be able to use GitHub, please follow the primer
at: https://reference.apache.org/committer/github


We appreciate your understanding of this issue, and hope that your
project can coordinate voluntarily moving your repositories in a
timely manner.

All settings, such as commit mail targets, issue linking, PR
notification schemes etc will automatically be migrated to gitbox as
well.

With regards, Daniel on behalf of ASF Infra.

PS:For inquiries, please reply to us...@infra.apache.org, not your 
project's dev list :-).

[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Daniel Gruno]

[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
 DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]

Hello Apache projects,

I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
months. All repositories will be moved to the new gitbox service which
includes direct write access on github as well as the standard ASF
commit access via gitbox.apache.org.

## Why this move? ##
The move comes as a result of retiring the git-wip service, as the
hardware it runs on is longing for retirement. In lieu of this, we
have decided to consolidate the two services (git-wip and gitbox), to
ease the management of our repository systems and future-proof the
underlying hardware. The move is fully automated, and ideally, nothing
will change in your workflow other than added features and access to
GitHub.

## Timeframe for relocation ##
Initially, we are asking that projects voluntarily request to move
their repositories to gitbox, hence this email. The voluntary
timeframe is between now and January 9th 2019, during which projects
are free to either move over to gitbox or stay put on git-wip. After
this phase, we will be requiring the remaining projects to move within
one month, after which we will move the remaining projects over.

To have your project moved in this initial phase, you will need:

- Consensus in the project (documented via the mailing list)
- File a JIRA ticket with INFRA to voluntarily move your project repos
  over to gitbox (as stated, this is highly automated and will take
  between a minute and an hour, depending on the size and number of
  your repositories)

To sum up the preliminary timeline;

- December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
  relocation
- January 9th -> February 6th: Mandated (coordinated) relocation
- February 7th: All remaining repositories are mass migrated.

This timeline may change to accommodate various scenarios.

## Using GitHub with ASF repositories ##
When your project has moved, you are free to use either the ASF
repository system (gitbox.apache.org) OR GitHub for your development
and code pushes. To be able to use GitHub, please follow the primer
at: https://reference.apache.org/committer/github


We appreciate your understanding of this issue, and hope that your
project can coordinate voluntarily moving your repositories in a
timely manner.

All settings, such as commit mail targets, issue linking, PR
notification schemes etc will automatically be migrated to gitbox as
well.

With regards, Daniel on behalf of ASF Infra.

PS:For inquiries, please reply to us...@infra.apache.org, not your 
project's dev list :-).

Re: [VOTE] Release httpd-2.4.36

[Daniel Gruno]

On 10/15/2018 04:20 PM, Stefan Eissing wrote:




Am 15.10.2018 um 16:11 schrieb Jim Jagielski :

It's up to the RM on whether or not to release... one can't veto a release and 
a -1 is not a veto.


Huh? I was referring to "TLS 1.3 support isn't quite yet tested enough to warrant a public 
release". I wanted to point out that without attempting a public release, we may not have 
found this bug for months. I am -1 on 2.4.36 as well, in case that was not clear. Don't know how 
this "veto" came into this...


I don't think it was directed at anyone, just a general note that even 
if we find faults with 2.4.36 we can't pull the release with a -1 unless 
everyone changes their minds, as releases can't be vetoed. The RM can 
choose to re-roll after some fixes have been done, but 2.4.36 will be 
burned off then.




-Stefan


On Oct 15, 2018, at 10:07 AM, Stefan Eissing  
wrote:




Am 15.10.2018 um 15:58 schrieb Jim Jagielski :

Considering all this, I am changing my vote from a +1 to a -1. I was not able to trigger this 
error, but this shows, at least IMO, that TLS 1.3 support isn't quite yet tested enough to warrant 
a public release, unless we are super clear that it is "experimental" or "early 
access"...


I do not see it this black/white way.

We have found no regression with any SSL != OpenSSL 1.1.1.
We have not even found a bug with TLSv1.3 as such. What we have found is a 
behaviour change in OpenSSL where our code relied on either changed or not well 
documented behaviour.

We do not want to ship a version of httpd which has severe interop problems 
with the released openssl 1.1.1.
HOWEVER: it is unclear, if this will not also trigger in some scenario when one 
links 2.4.35 with OpenSSL 1.1.1.

I am all in favor of pushing a 2.4.37 immediately after this bug is fixed. We 
will not solve any remaining problems by letting it stew in the repository.

-Stefan




On Oct 15, 2018, at 4:06 AM, Stefan Eissing  
wrote:




Am 14.10.2018 um 23:46 schrieb Daniel Ruggeri :

Hi, Helmut;
Note that the vote may run longer than 72 hours as 72 is the minimum. As it 
stands now, we have more than 3 binding +1 votes, but I am waiting for closure 
on the conversation on-list about the tests with reported H2/TLS 1.3 failures. 
Since this is one of the primary features of this release, I want to be sure 
the topic gets due attention.


See my mail on the other thread. It seems that h2 traffic triggers a call 
sequence that exposes a change in OpenSSL behaviour of SSL_read() between 1.1.0 
and 1.1.1. It looks as if mod_ssl interpreted the return codes of SSL_read() in 
a way that no longer works and that we need to change mod_ssl handling here.

Waiting on confirmation  or rebuttal of my analysis on the other thread.

Cheers,

Stefan


--
Daniel Ruggeri

On October 14, 2018 4:44:04 PM CDT, "Helmut K. C. Tessarek" 
 wrote:
On 2018-10-10 15:18, Daniel Ruggeri wrote:
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.36:
[ ] +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:
sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
sha256: ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
*httpd-2.4.36.tar.gz

72h have passed, so what is the outcome of the vote?

Re: [VOTE] Release httpd-2.4.35

[Daniel Gruno]

On 09/19/2018 10:56 AM, Stefan Eissing wrote:

-1, the tag is not from HEAD of 2.4.x.

Specifically it seems to me it is missing:

r1840757 | jim | 2018-09-12 22:38:02 +0200 (Mi, 12 Sep 2018) | 12 lines

Merge r1840010 from trunk:

...

Can someone confirm that the tag seems to miss changes at the time it was done?


Cannot confirm, the merge is present in the 2.4.35 tag.
Where are you not seeing your changes?

I checked 
http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.35/modules/http2/h2_session.c?view=markup 
and the changes are there..




-Stefan


Am 18.09.2018 um 02:56 schrieb Daniel Ruggeri :

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.35:
[ ] +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:
md5: 92ddccfbd43b533578499d1faaad17fe *httpd-2.4.35.tar.gz
sha1: b7996c2c1f7ff5bb217114fe5354a19a5207ab62 *httpd-2.4.35.tar.gz
sha256: 31c2c82c9cd34749cbb60d04619d9aa3fb0814ab22246ad588d2426dde90c72c
*httpd-2.4.35.tar.gz

--
Daniel Ruggeri

Re: 2.4.x and 2.6.x ... next steps

[Daniel Gruno]

On 09/12/2018 10:58 AM, Graham Leggett wrote:
On 12 Sep 2018, at 03:15, William A Rowe Jr > wrote:


On Tue, Sep 11, 2018, 17:42 Graham Leggett > wrote:


On 11 Sep 2018, at 20:35, Jim Jagielski mailto:j...@jagunet.com>> wrote:

> This is what I propose:
>
>  o Later on this week I svn cp trunk over to branches/2.5.x


-1 ... Veto on the basis of project bylaws. Propose a revision for voting.


I've totally lost you. Jim describes creating a branch, how is this 
related to voting?


I am not Bill, but it is likely a reference to the fact that you can 
veto code changes, not community/workflow changes. I see Jim's proposal 
as the latter, so I'm not sure why the attempted veto. The codebase 
itself isn't being changed from what I can gather, only the workflow is.


With regards,
Daniel.



Rather than a wall of text, can you propose corrections to the above?

This is an attempt to discard the work of all committers who were told 
their code wouldn't be included until the next version major.minor. 
Complete disenfranchisement via a pocket veto of all changes.


Again, totally lost you. I can’t see anything in Jim’s proposal that 
suggests we throw away code or work from trunk, and I would not allow 
that to happen either. Have you mixed up the messages you’ve replied to?


Regards,
Graham
—

Re: [apache/httpd] Add Option to generate multiple error logs of different format in Apache 2.4.x (#52)

[Daniel Gruno]

On 06/06/2018 02:21 AM, Micha Lenk wrote:

Hi all,

on Github the pull request #52 https://github.com/apache/httpd/pull/52 
looks like it has gone wild, receiving new commits from asfgit every 
once in a while. The pull request itself looks unusable. Does anybody 
know who created it and who is updating it?


Regards,
Micha


It's a perpetual PR, as it's trying to merge 2.4.x with trunk, which 
means it will always update whenever something new is pushed to httpd.

I've closed the ticket.




On 06/05/2018 08:59 PM, asfgit wrote:

@asfgit  pushed 1 commit.

  * 2274d83  Use define
    for serverroot with Windows conf files.

—
You are receiving this because you are subscribed to this thread.
View it on GitHub 
 
or mute the thread 
. 

Re: Vote 2.4.32 and mod_md no valid Certificate Agreement directive

[Daniel Gruno]

Would it be possible to just have a link that always points to the
_current_ agreement, much like our docs have a /current/ directory that
always fetches you the current 2.4 docs?

On 03/12/2018 11:03 AM, Stefan Eissing wrote:
> 
> 
>> Am 12.03.2018 um 10:39 schrieb Luca Toscano :
>>
>> Hi Stefan!
>>
>> 2018-03-12 10:29 GMT+01:00 Stefan Eissing :
>> The recommended URL in our docs is wrong. The wrong one was introduced in 
>> r1820464.
>> Supposedly as a fix to PR 35622. The proposed patch in the PR 35622 however
>> carries the correct URL. Not sure how that happened. It should be changed in 
>> the docs.
>>
>> This elukey committer always makes mistakes, I am going to follow up with 
>> him to make sure he stops :D :D :D
> 
> He is a real DareDevil!
> 
>> Jokes aside, iirc I think I checked in https://letsencrypt.org/repository/ 
>> and copied the link "currently in effect", that now is:
>>
>> https://letsencrypt.org/documents/2017.11.15-LE-SA-v1.2.pdf
>>
>> So possibly the Let's encrypt documentation needs to be fixed as well? I'll 
>> amend the link today in the docs though! 
> 
> I will contact LE. I think they need to accept the set of agreement URLs they 
> use themselves on the site.
> 
> Cheers,
> 
> Stefan
> 
>>
>>> Not sure this can voted as  a -1 for 2.4.32 ?
>>
>> It certainly can. The more relevant question is: should it? 
>>
>> I think not, it is a documentation change only, let's keep testing 2.4.32 :)
>>
>> Luca 
> 

Re: [VOTE] Release httpd-2.4.31

[Daniel Gruno]

On 03/03/2018 04:56 PM, Daniel Ruggeri wrote:
> Hi, all;
> 
>    Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/

I know this is a bit nitpicky, and we don't do this in all projects,
but...can we please have the tarball digest in the vote thread in the
future? svn history aside, the tarballs could be overridden during a
vote, and we'd not know immediately unless we have an md5 or sha digest
we're sure the vote is about.

With regards,
Daniel.

> 
>  
> 
> I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.31:
> 
>  
> 
> [ ] +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.
> 
>  
> 
> -- 
> 
> Daniel Ruggeri
> 
>  
> 

Re: apr "the latest available version"

[Daniel Gruno]

On 10/26/2017 12:44 PM, Reindl Harald wrote:
> 
> 
> Am 26.10.2017 um 12:38 schrieb Graham Leggett:
>> On 26 Oct 2017, at 12:31 PM, Reindl Harald 
>> wrote:
>>
>>> i am not going to subscribe to every single devel list out there for
>>> single issues and had already submitted a bug as 1.6.x was over
>>> months invisible when you expect that the top part of the page is recent
>>
>> Please tone down the aggressive behaviour
> 
> i don't see any aggressive here
> 
> sorry for pointing out a issue trying to help others which probably
> don't realize and hence not update their servers while i personally
> could not care less after knowing that i have to scroll down

I, and many others do, and this is not the first time we've had to deal
with negativities. It is a toll on our mental states in the long run -
something I'd rather be without. I have unsubscribed reindl from the
list, he is not welcome for the time being.

Re: apr "the latest available version"

[Daniel Gruno]

On 10/25/2017 06:23 PM, Reindl Harald wrote:
> it is *not* helpful when you already have deployed httpd 2.4.29 that you
> by random luck face a apr-1.6.3 build on the fedora buildserver

I'd suggest you post this to d...@apr.apache.org if you want them to
update their dist page.

With regards,
Daniel.

> (https://koji.fedoraproject.org/koji/buildinfo?buildID=989222) either
> this stuff on top should be removed completly or properly updated, if
> it's not there at all one would look at the filelist
> 
> https://www.apache.org/dist/apr/
> 
> Important Notices
>     Download from your nearest mirror site!
>     APR 1.6.2 is the latest available version
>     APR-util 1.6.0 is the latest available version
>     APR-iconv 1.2.1 is the latest available version
> 
> APR 1.6.2 is the latest available version
> 
> APR 1.6.2 has been released, and should be considered "general
> availability".
> APR-util 1.6.0 is the latest available version
> 
> APR-util 1.6.0 has been released, and should be considered "general
> availability".

Re: Time for 2.4.28 ?

[Daniel Gruno]

On 09/18/2017 06:24 PM, Jim Jagielski wrote:
> Seems like a good time to push for a 2.4.28 T by end-of-week.
> Review STATUS! Test and Vote on backports!
> 
> Comments?
> 
+1!

flood 0.4 was never signed for?

[Daniel Gruno]

Hi folks,

It appears that flood 0.4 (
https://dist.apache.org/repos/dist/release/httpd/flood/ ) was never
signed by anyone, which should likely be fixed. As this was, AIUI,
released 8 years ago, I cannot in good conscience sign for it myself.

Either we have someone who was present back then sign for it, or we
should remove the release, pursuant to our release policy.

With regards,
Daniel.

Re: ACNA Miami: Who? When?

[Daniel Gruno]

On 05/08/2017 08:00 PM, Jim Riggs wrote:
> So, who all will be in Miami? From what I've seen on Sched and messages here:
> 
> Yes : jimjag, rich, jfc, ruggeri, me
> No  : rowe, covener
> 
> There are several other ACNA regulars who have been quiet around here lately. 
> Anyone else coming in?

I'm giving a talk at ACNA, so I better be there :D
I'll be there all week, might even have some surprises as usual (the old
timers will know of what I speak...)

> 
> I'll be there Sunday evening through Friday morning. I would update 
> https://wiki.apache.org/httpd/Face2Face like usual, but it got locked down 
> for spam.
> 
> I'm up for a meal with any of you anytime. Also, contrary to the seeming 
> consensus on the hackathon thread a couple weeks ago (that I missed), I have 
> had a lot of luck pounding things out during random hacking sessions or down 
> times at the conference, most notably that 
> mod_cache-thundering-herd-lock-file issue that a group of us really hammered 
> on a couple years back. (It was absolutely killing me at work!) That said, 
> I'm always up for hacking on stuff with people, especially when it's 
> something nagging like that.
> 

Re: server-status script donated to ASF

[Daniel Gruno]

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 <humbed...@apache.org> 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 <humbed...@apache.org> wrote:
>>>>
>>>> FWIW, the stuff that powers https://httpd.apache.org/server-status has
>>>> now been donated to the HTTPd project.
>>>>
>>>> With regards,
>>>> Daniel.
>>>
>>
> 

Re: server-status script donated to ASF

[Daniel Gruno]

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 <humbed...@apache.org> wrote:
>>
>> FWIW, the stuff that powers https://httpd.apache.org/server-status has
>> now been donated to the HTTPd project.
>>
>> With regards,
>> Daniel.
> 

server-status script donated to ASF

[Daniel Gruno]

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

With regards,
Daniel.

Re: JSON for mod_status

[Daniel Gruno]

On 01/18/2017 03:48 PM, Daniel Gruno wrote:
> On 01/18/2017 03:19 PM, Luca Toscano wrote:
>>
>>
>> 2017-01-18 10:56 GMT+01:00 Daniel Gruno <humbed...@apache.org
>> <mailto:humbed...@apache.org>>:
>>
>> 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
>> <https://httpd.apache.org/server-status> :)
>> JSON: http://httpd.apache.org/server-status?view=json_status
>> <http://httpd.apache.org/server-status?view=json_status>
>>
>>
>> Really nice work! I'd really like to see (if the author agrees :P) some
>> mod_lua scripts shipped with the httpd release and referenced in our
>> documentation. 
> 
> Hey, it's ALv2, always has been - if we wanna ship it, so be it :)
> It's at https://github.com/Humbedooh/server-status at the moment, and
> needs a tiny bit of cleanup if it's to be shipped.

I tidied up the code and refactored the JSON format.
HTML view: http://httpd.apache.org/server-status
JSON: http://httpd.apache.org/server-status?view=json
Extended JSON:
http://httpd.apache.org/server-status?view=json=true (LOT OF
DATA :p)

Feedback/suggestions are most welcome.
I'll likely donate this to httpd after FOSDEM if there's an interest in
that.

With regards,
Daniel.

> 
> With regards,
> Daniel.
> 
>>
>> Luca
>>
> 

Re: JSON for mod_status

[Daniel Gruno]

On 01/18/2017 03:19 PM, Luca Toscano wrote:
> 
> 
> 2017-01-18 10:56 GMT+01:00 Daniel Gruno <humbed...@apache.org
> <mailto:humbed...@apache.org>>:
> 
> 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
> <https://httpd.apache.org/server-status> :)
> JSON: http://httpd.apache.org/server-status?view=json_status
> <http://httpd.apache.org/server-status?view=json_status>
> 
> 
> Really nice work! I'd really like to see (if the author agrees :P) some
> mod_lua scripts shipped with the httpd release and referenced in our
> documentation. 

Hey, it's ALv2, always has been - if we wanna ship it, so be it :)
It's at https://github.com/Humbedooh/server-status at the moment, and
needs a tiny bit of cleanup if it's to be shipped.

With regards,
Daniel.

> 
> Luca
> 

Re: JSON for mod_status

[Daniel Gruno]

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: JSON for mod_status

[Daniel Gruno]

On 11/30/2016 07:20 PM, Jordan Gigov wrote:
> I think a better approach than "?json=true" would be to to respect the
> "Accept" header values of "application/json" and "text/json" if they
> have the higher priority.

Or both? Practically speaking, showing JSON based on a query arg is
vastly easier for laymen to implement in their applications than setting
accept headers, AND you can query and get JSON in your browser also.

> XML output should also be an option, if it will indeed serve as an API
> end-point.

Meh, I honestly have not used XML in a decade, so I'm +/-0 on that one.
If someone wants to do it, fine, but .. :p

> 
> On 30 November 2016 at 20:08, Luca Toscano <toscano.l...@gmail.com> wrote:
>>
>>
>> 2016-11-30 19:03 GMT+01:00 Daniel Gruno <humbed...@apache.org>:
>>>
>>> On 11/30/2016 06:54 PM, Jim Jagielski wrote:
>>>> 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...?
>>
>>
>> +1, this will simplify a lot things like metrics collectors polling httpd
>> regularly (that don't need a nice html format).
>>
>>> +1, a ?json=true or some such to the query would be helpful.
>>> so you could do
>>> /server-status?json=true
>>> or
>>> /server-status?auto=true
>>>
>>
>> +1, I like the idea!
>>
>> Thanks!
>>
>> Luca
>>

Re: JSON for mod_status

[Daniel Gruno]

On 11/30/2016 06:54 PM, Jim Jagielski wrote:
> 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...?
> 
+1, a ?json=true or some such to the query would be helpful.
so you could do
/server-status?json=true
or
/server-status?auto=true

etc.

Re: Thoughts on using HW for httpd?

[Daniel Gruno]

Since it's only been +1s, I plan to put the widget on our site today.
It's on httpd.staging.apache.org if anyone wants to preview it, yell if
you disagree :-)

With regards,
Daniel.

On 02/12/2016 09:11 PM, Luis Gil wrote:
> love it!  
> 
> El vie., 12 de febrero de 2016 13:20, Daniel Gruno <humbed...@apache.org
> <mailto:humbed...@apache.org>> escribió:
> 
> Hi folks,
> as some may know, ComDev is trialling a new thing called 'Help Wanted!'
> at https://helpwanted.apache.org/
> 
> I've added a few example entries for httpd, and I'm wondering if this is
> something we would want to plug into our web site?
> 
> You can see an example web site widget at
> https://helpwanted.apache.org/wtest.html (top one shows httpd)
> 
> It's an easy way to identify which tasks we'd love to see someone get
> started on (and has the benefit of being able to assign difficulty
> levels, skills needed etc to a task), and judging from the input on the
> existing tasks, it seems to attract people towards projects.
> 
> Thoughts? flames? snark? :)
> 
> With regards,
> Daniel.
> 
> -
> To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
> <mailto:docs-unsubscr...@httpd.apache.org>
> For additional commands, e-mail: docs-h...@httpd.apache.org
> <mailto:docs-h...@httpd.apache.org>
> 
> -- 
> 
> Luis J.G
> 

Thoughts on using HW for httpd?

[Daniel Gruno]

Hi folks,
as some may know, ComDev is trialling a new thing called 'Help Wanted!'
at https://helpwanted.apache.org/

I've added a few example entries for httpd, and I'm wondering if this is
something we would want to plug into our web site?

You can see an example web site widget at
https://helpwanted.apache.org/wtest.html (top one shows httpd)

It's an easy way to identify which tasks we'd love to see someone get
started on (and has the benefit of being able to assign difficulty
levels, skills needed etc to a task), and judging from the input on the
existing tasks, it seems to attract people towards projects.

Thoughts? flames? snark? :)

With regards,
Daniel.

Re: Thoughts on using HW for httpd?

[Daniel Gruno]

On 02/12/2016 02:06 PM, Luca Toscano wrote:
> +1!
> 
> I really like this idea, especially for new committers/volunteers like
> me looking for things to work on. I would also add a section related to
> "how to find help if you get stuck" or "How to send your code/work for
> review".

I think the 'how to' stuff would be unique to httpd and thus belong in
our docs area. HW has a 'contribution help URL' parameter you can set,
so we could just point that to whatever contributor docs we have/want.

> 
> Really interested, if you need any help I'll be available :) 

Glad to hear that :) As you are a committer, you already have access to
add tasks on HW (click the 'add/edit tasks' link) if you can think of
anything we might want people to look into :)

With regards,
Daniel.
> 
> Luca
> 
> 
> 
> 2016-02-12 13:35 GMT+01:00 Yann Ylavic <ylavic@gmail.com
> <mailto:ylavic@gmail.com>>:
> 
> +1!
> 
> On Fri, Feb 12, 2016 at 1:27 PM, Jim Jagielski <j...@jagunet.com
> <mailto:j...@jagunet.com>> wrote:
> > /me like
> >
> >> On Feb 12, 2016, at 7:20 AM, Daniel Gruno <humbed...@apache.org
> <mailto:humbed...@apache.org>> wrote:
> >>
> >> Hi folks,
> >> as some may know, ComDev is trialling a new thing called 'Help
> Wanted!'
> >> at https://helpwanted.apache.org/
> >>
> >> I've added a few example entries for httpd, and I'm wondering if
> this is
> >> something we would want to plug into our web site?
> >>
> >> You can see an example web site widget at
> >> https://helpwanted.apache.org/wtest.html (top one shows httpd)
> >>
> >> It's an easy way to identify which tasks we'd love to see someone get
> >> started on (and has the benefit of being able to assign difficulty
> >> levels, skills needed etc to a task), and judging from the input
> on the
> >> existing tasks, it seems to attract people towards projects.
> >>
> >> Thoughts? flames? snark? :)
> >>
> >> With regards,
> >> Daniel.
> >
> 
> 

Re: [users@httpd] Block access to "OPTIONS *"

[Daniel Gruno]

On 02/12/2016 01:28 PM, Jim Jagielski wrote:
> Blocking OPTIONS has a long and illustrious history...
> I am -0 on doing anything more related to it ;)
> 

Isn't that why we have the optional mod_allowmethods these days anyway...

With regards,
Daniel.

Re: 2.4.18?

[Daniel Gruno]

I don't care who the author is - if people keep up with toxic language
like what has been used in this thread, they will be removed from the
lists without any further warning.

Consider this your first, last and only warning. I trust I don't have to
go into details about who said what here.

With regards,
Daniel.

Re: Moderations for modules.apache.org

[Daniel Gruno]

On 11/9/2015, 1:54:59 PM, Graham Leggett <minf...@sharp.fm> wrote: 
> On 09 Nov 2015, at 2:41 PM, Daniel Gruno <humbed...@apache.org> wrote:
> 
> > You're welcome to try to clean it up ;)
> > make a user account on the system and give me the UID of that user (the
> > ID, not the username - there are tens of thousands of users, so I can't
> > see them all in the admin interface anymore).
> 
> :)
> 
> > I am contemplating removing all users/mods and adding some recaptcha
> > stuff to it soon, but enotime right now.
> 
> Is there a way to leverage LDAP at all? (Or whatever backs the JIRA et al 
> instances)
> 

JIRA isn't LDAP backed, FWIW.
And no, we wanted it to be open to the larger public to submit modules, not 
just committers. But the rub is, we are being attacked manually by actual 
people sending in garbage stuff, bypassing the security checks. I'm not 
entirely sure how to combat this, but I do have a few ideas. They require 
something close to a complete wipe of the database , however.

With regards,
Daniel.

> Regards,
> Graham
> —
> 
> 
--
Sent via Pony Mail for dev@httpd.apache.org. 
View this email online at:
https://pony-poc.apache.org/list.html?dev@httpd.apache.org

Re: Moderations for modules.apache.org

[Daniel Gruno]

I'm a bit slow this morning. I'm sitting here, using Pony Mail for replying, 
not realizing...we should use OAuth for this! It would still require a wipe of 
the current DB, but if we use the ASF OAuth plus maybe Google OAuth for 
non-committers, we should be able to allow only _actual people_ to contribute 
to this. :)

Does this sound like a good idea, or complete overkill?

With regards,
Daniel.

On 11/9/2015, 1:54:59 PM, Graham Leggett <minf...@sharp.fm> wrote: 
> On 09 Nov 2015, at 2:41 PM, Daniel Gruno <humbed...@apache.org> wrote:
> 
> > You're welcome to try to clean it up ;)
> > make a user account on the system and give me the UID of that user (the
> > ID, not the username - there are tens of thousands of users, so I can't
> > see them all in the admin interface anymore).
> 
> :)
> 
> > I am contemplating removing all users/mods and adding some recaptcha
> > stuff to it soon, but enotime right now.
> 
> Is there a way to leverage LDAP at all? (Or whatever backs the JIRA et al 
> instances)
> 
> Regards,
> Graham
> —
> 
> 
--
Sent via Pony Mail for dev@httpd.apache.org. 
View this email online at:
https://pony-poc.apache.org/list.html?dev@httpd.apache.org

Re: Moderations for modules.apache.org

[Daniel Gruno]

On 11/09/2015 01:25 PM, Graham Leggett wrote:
> On 06 Nov 2015, at 6:55 PM, Daniel Gruno <humbed...@apache.org> wrote:
> 
>> I'm sorry to say modules.apache.org is so bot/spam infested now, that
>> it's impossible to moderate it unless I spend more than an hour every
>> day going through all the fake modules and users added on a daily basis.
>>
>> I am contemplating scrapping it entirely, or possibly creating a new
>> system at some point, with stronger anti-spam measures.
> 
> Need a hand with moderation?
> 
> Having what looks to be the formal module search engine being frozen in time 
> is a problem for us, it makes us look stale when we aren’t.
> 
> Regards,
> Graham
> —
> 
You're welcome to try to clean it up ;)
make a user account on the system and give me the UID of that user (the
ID, not the username - there are tens of thousands of users, so I can't
see them all in the admin interface anymore).

I am contemplating removing all users/mods and adding some recaptcha
stuff to it soon, but enotime right now.

With regards,
Daniel.

Re: Moderations for modules.apache.org

[Daniel Gruno]

On 11/06/2015 05:53 PM, Graham Leggett wrote:
> Hi all,
> 
> I've had a module waiting to be approved at modules.apache.org for a while, 
> anyone know who the moderator is?
> 
> Regards,
> Graham
> --
> 
Hi Graham,
I'm sorry to say modules.apache.org is so bot/spam infested now, that
it's impossible to moderate it unless I spend more than an hour every
day going through all the fake modules and users added on a daily basis.

I am contemplating scrapping it entirely, or possibly creating a new
system at some point, with stronger anti-spam measures.

with regards,
Daniel.

Re: Thx and merit

[Daniel Gruno]

Indeed, +1!

With regards,
Daniel

On 10/14/2015, 2:58:48 PM, Jim Jagielski  wrote: 
> The ASF is all about recognizing and rewarding merit. The whole
> "Apache Way" started here, with this project, and httpd has always
> been the sort of "guiding light" and example of how Apache projects
> (should) work.
> 
> Inclusion of the HTTP/2 implementation for httpd, especially for
> the 2.4.x branch, is a substantial feather in our cap. But we
> would have been far behind the 8-ball if not for the funding by
> the GSM Association on greenbytes GmbH's mod_h2 work, and for
> the donation of that module to the ASF.
> 
> Once again, I'd like to thank them personally!
> 
--
Sent via Pony Mail for dev@httpd.apache.org. 
View this email online at:
https://pony-poc.apache.org/list.html?dev@httpd.apache.org

Re: svn commit: r10796 - /release/httpd/

[Daniel Gruno]

On 10/13/2015 01:12 PM, Yann Ylavic wrote:
> On Mon, Oct 12, 2015 at 7:42 PM,   wrote:
>> Author: jim
>> Date: Mon Oct 12 17:42:21 2015
>> New Revision: 10796
>>
>> Log:
>> Push and populate mirrors...
> 
> Despite this commit, httpd.a.o (including /download.cgi) still refers
> to 2.4.16 for me (EU, but same for httpd.us.a.o), although
> www.a.o/dist/httpd/Announcement2.4.html and /dist/httpd/CHANGES_2.4
> have been updated to 2.4.17.
> 
The mirrors need to populate before we can change it to 2.4.17.
Give it a few hours :)

With regards,
Daniel.

Re: GitHub (mirror) pull requests notifications

[Daniel Gruno]

On 10/09/2015 11:12 AM, Yann Ylavic wrote:
> Could they somehow be sent to dev@, or is there legal issues?
> 
No, nothing legal there...just that people didn't want GH integration ;)
If there's a desire to have it enabled, we can make it so..

With regards,
Daniel.

Re: [VOTE] Release Apache httpd 2.4.17 as GA

[Daniel Gruno]

On 10/09/2015 07:40 PM, Jim Jagielski wrote:
> The pre-release test tarballs for Apache httpd 2.4.17 can be found
> at the usual place:
> 
>   http://httpd.apache.org/dev/dist/
> 
> I'm calling a VOTE on releasing these as Apache httpd 2.4.17 GA.
> 
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
> 
> Vote will last the normal 72 hrs.
> 
> NOTE: The *-deps are only there for convenience.
> 
> Thx!
> 

+1 (binding)

I ran it through my usual tests, results at
http://compliance.rocks/result.html?1e67b9ba

Might need to tweak some headers, but meh..

configure, compile, install, run - all works fine (Ubuntu 14.04).
AAAND it installs mod_lua just fine, so yay!

With regards,
Daniel.

Re: T of 2.4.17 this week

[Daniel Gruno]

On 10/06/2015 02:01 PM, Jeff Trawick wrote:
> On Tue, Oct 6, 2015 at 7:44 AM, Daniel Gruno <humbed...@apache.org
> <mailto:humbed...@apache.org>> wrote:
> 
> On 10/05/2015 06:35 PM, Daniel Gruno wrote:
> > +1!
> > There's so much new goodness we have to share! :)
> >
> > On 10/5/2015, 5:54:04 PM, Jim Jagielski <j...@jagunet.com> wrote:
> >> I propose a T of 2.4.17 this week with a release for next. I
> >> will RM.
> >>
> >> Comments?
> >>
> 
> Also, if someone could verify that the tweaks I made to mod_lua makes it
> compile properly on Ubutnu 14.04 (with lua5.2-dev installed), that would
> be super swell!
> 
> 
> The build looks okay here, but I haven't tried any scripts...

Awesome, as long as the .so file gets built, I'm happy :)
Thanks for checking!

With regards,
Daniel.

Re: T of 2.4.17 this week

[Daniel Gruno]

On 10/05/2015 06:35 PM, Daniel Gruno wrote:
> +1!
> There's so much new goodness we have to share! :)
> 
> On 10/5/2015, 5:54:04 PM, Jim Jagielski <j...@jagunet.com> wrote: 
>> I propose a T of 2.4.17 this week with a release for next. I
>> will RM.
>>
>> Comments?
>>

Also, if someone could verify that the tweaks I made to mod_lua makes it
compile properly on Ubutnu 14.04 (with lua5.2-dev installed), that would
be super swell!

With regards,
Daniel.

Re: T of 2.4.17 this week

[Daniel Gruno]

+1!
There's so much new goodness we have to share! :)

On 10/5/2015, 5:54:04 PM, Jim Jagielski  wrote: 
> I propose a T of 2.4.17 this week with a release for next. I
> will RM.
> 
> Comments?
> 

Re: svn commit: r1706637 - /httpd/httpd/trunk/modules/http2/config.m4

[Daniel Gruno]

On 10/04/2015 04:22 PM, Jeff Trawick wrote:
> 
> This is CTR in the 2.4.x branch, right?  (i.e., can just commit it?)
> 

Yeah, it was informally decided (last week) to CTR the http2 stuff.

With regards,
Daniel.

Re: Lua coroutines

[Daniel Gruno]

Not to mention that should we opt for the Lua coroutines, this would 
also indirectly mean it would be possible to dynamically alter the HTTP 
process using custom scripts, which could be very interesting :) sort of 
like mod_lua on steroids ;). Other ways this could be used would be unit 
testing, where you could inject things into every crevice of httpd 
dynamically without having to recompile when you change the test.


With regards,
Daniel.

On 2015-09-26 19:10, Jim Jagielski wrote:

I've been keen on libmill, which provides a golang-like
goroutine library. It seems that such functionality would
be cool for httpd

Then I started thinking: Lua also has a great coroutine impl
and it is also MIT licensed and might be easier to fold
into httpd. Anyone ever look at that? Having something like
ap_routine() would be awful cool. We already have some Lua
expertise here and being able to use native coroutines in httpd
itself would be very neat, esp for 2.6/3.0

Re: question about mod_lua's status

[Daniel Gruno]

On 09/20/2015 10:00 PM, Guilherme Macedo - BlueSecure wrote:
> Hi.
> 
> Does anyone know why mod_lua is still in experimental status and if
> there is any plan for it to go to extension or base?
> 
> Thanks in advance.
> 
> Guilherme Macedo | bluesecure.com.br

The experimental status refers to the fact that the API may change from
release to release. The module itself is stable and is used in
production in many places (we use it at Apache ourselves on servers with
millions of daily requests). It is considered a part of the official
releases, although some distros have failed to include it properly (I
believe in part because of some packaging issues).

So, to sum up: the module works, but we may decide to alter it a bit
from time to time, hence the 'experimental' status sticking to it.

With regards,
Daniel.

Re: mod_lua unable to delete cookie

[Daniel Gruno]

Hi Mark,
you have to give it a number different from 0, because of how the
internals work. This is an "optional integer" which falls back to 0 if
nothing is given, and if 0, then it's not written.
Set it to the past using os.time instead:

r:setcookie{
  key = 'foobar',
  value = 'blah',
  expipres = os.time() - 1
}

With regards,
Daniel.

On 09/03/2015 03:51 PM, Mark Taylor wrote:
> Calling setcookie(..) with expires=0 does not set expires to the epoch time
> on the client.
> 
> To delete a cookie client side, conventional wisdom is to set expires to
> the epoch time:
> 
> http://stackoverflow.com/questions/5285940/correct-way-to-delete-cookies-server-side
> 
> When setting expires=0 in setcookie, modules/lua/lua_requests.c
> lua_set_cookie() function skips adding the expires field to the cookie in
> Set-Cookie header sent back to client.
> 
> The fix is pretty simple, time zero should be the epoch anyway?
> 
> -Mark
> 

Re: Helping out with release testing

[Daniel Gruno]

Anyone is free to test and help out, and frankly, we'd highly appreciate 
it if you did :).
As for the voting; Anyone can vote on a release, but only committers can 
cast binding votes.
Having said that, if anyone - even a non-committer - casts a -1, it WILL 
cause us to pause and think about it, discuss etc.


We value input from our users, and anyone that can help out test a 
release will have our thanks and respect, and your opinions and findings 
WILL be taken into consideration.


With regards,
Daniel.

On 2015-07-13 14:21, Jacob Perkins wrote:
Agreed! I’d love to be able to spin up a new HTTPD release and send it 
through both httpd testing platform and our own testing platform.


—
Jacob Perkins
Product Owner
*cPanel Inc.*

jacob.perk...@cpanel.net mailto:jacob.perk...@cpanel.net
Office:  713-529-0800 x 4046
Cell:  713-560-8655

On Jul 13, 2015, at 7:17 AM, Kean Johnston kean.johns...@gmail.com 
mailto:kean.johns...@gmail.com wrote:


Hi devs,

As each release goes by I see the same few people involved with 
testing. It seems like a lot of work and I would like to help spread 
the load a little. Is it only committers than can participate in this 
process or do you invite help from others?


I can help test on the common platforms, viz. CentOS 7, Mac OSX 
10.10.4 and Debian, which I see a number of people already test. 
However, if me testing on those platforms may free up their time to 
test on other more exotic systems that I do not have access to, I am 
very happy to do so.


Please let me know how I can help out.

Sincerely,
Kean

Re: Helping out with release testing

[Daniel Gruno]

There is actually an ambiguity in our policy on that. We should fix it ;)

With regards,
Daniel.

On 2015-07-13 14:42, Eric Covener wrote:

On Mon, Jul 13, 2015 at 8:25 AM, Daniel Gruno humbed...@apache.org wrote:

As for the voting; Anyone can vote on a release, but only committers can
cast binding votes.
Having said that, if anyone - even a non-committer - casts a -1, it WILL cause 
us to pause and think about it, discuss etc.

Strictly speaking, it is  PMC members votes that are binding. But this
is almost meaningless from a quality perspective and the distinction
shouldn't dissuade anyone from testing candidates when they can.

Re: mod_lua: Accessing multiple Set-Cookie response headers

[Daniel Gruno]

This should really go to users@, but anyway...
You might want to take a look at:

http://modlua.org/api/builtin#getcookie
http://modlua.org/api/builtin#setcookie

With regards,
Daniel.

On 2015-05-18 16:53, Christian Folini wrote:

Hello,

Mod_lua gave me a few quick wins when I started to play around
with cookies on a reverse proxy. But then the obvious happened:
the backend started to issue multiple Set-Cookie response headers
in the same http response.

mod_lua returns the headers via r.headers_out, but while the
documentation states the return value is of lua-type table,
it is actually of lua-type userdata and I can not seem my way
around accessing more then a single Set-Cookie header per
request. The latter is done via r.headers_out['Set-Cookie'],
but now I got stuck.

Any ideas?

Best,

Christian Folini

Re: svn commit: r1643179 - in /httpd/httpd/trunk/server/mpm: prefork/prefork.c worker/worker.c

[Daniel Gruno]

I'm working on that right now, Yann :)

With regards,
Daniel.
On 2014-12-05 13:40, Yann Ylavic wrote:

On Fri, Dec 5, 2014 at 8:57 AM,  yla...@apache.org wrote:

Author: ylavic
Date: Fri Dec  5 07:57:57 2014
New Revision: 1643179

URL: http://svn.apache.org/viewvc?rev=1643179view=rev

The URL used here seems to have changed since recent upgrade (was
httpd://svn.a.o/r[rev] before).
The previous one looked more generic IMHO, less dependant on the SVN
viewer (would not break if the viewer changes some day).

Re: svn commit: r1643179 - in /httpd/httpd/trunk/server/mpm: prefork/prefork.c worker/worker.c

[Daniel Gruno]

All fixed now - took a bit of digging, but it works :)

On 2014-12-05 13:43, Yann Ylavic wrote:

OK, thanks Daniel.

On Fri, Dec 5, 2014 at 1:41 PM, Daniel Gruno humbed...@apache.org wrote:

I'm working on that right now, Yann :)

With regards,
Daniel.

On 2014-12-05 13:40, Yann Ylavic wrote:

On Fri, Dec 5, 2014 at 8:57 AM,  yla...@apache.org wrote:

Author: ylavic
Date: Fri Dec  5 07:57:57 2014
New Revision: 1643179

URL: http://svn.apache.org/viewvc?rev=1643179view=rev

The URL used here seems to have changed since recent upgrade (was
httpd://svn.a.o/r[rev] before).
The previous one looked more generic IMHO, less dependant on the SVN
viewer (would not break if the viewer changes some day).

Re: Change of web site layout

[Daniel Gruno]

On 06/17/2014 12:46 AM, Tim Bannister wrote:
 On 16 Jun 2014, at 22:23, Rich Bowen wrote:
 

 Apache httpd being #1 on the internet is great news, but personally I'd put 
 that on the carousel. What sort of leading text should go in its place? I'm 
 happy to put some work into this.

 Also, it's the text that's been on our website for at least 15 years. So, 
 yeah, it's probably time to say something different here.
 
 …or say it differently? I've made my own mock up front page (attached), which 
 can be a straw man for further discussion. I based this, as you may well have 
 guessed, on the design and styles used at http://www.apache.org/
 
 This mockup mentions the #1 position and the 1 years but in its own way.
 
I like the idea of putting versions into tabs instead of littering the
front page with a lot of useless text that you may or may not want to
read. We should be pushing 2.4, and as such, that should be the first
thing any user sees (they can then click on the 2.2 tab to see 2.2 news :p).

I also like that you kept the release news short, we don't really need
to say we're so and so proud of presenting this in conjunction with
them and them, we need to simply say there's a new version, it
fixes/enhances this and that, go download it or read the changelog.

I have tried to incorporate your suggestions into my own proposal, and
the result can be seen at http://httpd.apache.pw/index2

In addition, I have some comments about your design proposal:

- The apache.org design might be changing RSN (it's being discussed),
  so using it might not be the most optimal route.
- Using the apache.org design will require making a ton of new pages,
  as the menu is not as complex as the original design or my proposal.
- Where are the download/changelog links? We need to push that, not
  hide it away.
- The user guide/tips is a great idea on paper, but would require yet
  more new documents, which won't be done until November (at ApacheCon).
  perhaps we could just add those to the carousel?
- Adding a search bar is always fun to do, but we don't have the tech
  to implement a search as it is, unless we use Google (which people can
  just use themselves)
- You use JavaScript to display the tabs. This, apparently, needs to be
  done in a way that people without JS can view it as well. I have tried
to accommodate that in my second proposal (see link above).
- The documentation link just leads to our boring and unattractive docs
  front page. I would prefer if people can go directly to documentation
  for e.g. 2.4 right away from the front page (dropdowns?).

I see this discussion going two ways now:

1) Which overall layout should we pick for the site?
2) How do we present out project on the front page?

I think both proposals are valid, and I won't go into who's got the
prettiest design, as that's entirely personal opinions, but I think the
second proposal leaves people wondering where can I get it, and where
can I find the changelog/docs/release notes quickly. Not that there
aren't links to some of it, it's just not that obvious where to click.

I'm running out of keyboard here, so I'll pause for a while and think
some more on the subject.
 
 
 
 
 -
 To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
 For additional commands, e-mail: docs-h...@httpd.apache.org
 

Re: Change of web site layout

[Daniel Gruno]

On 06/16/2014 10:38 AM, Greg Stein wrote:
 On Mon, Jun 16, 2014 at 3:00 AM, André Malo n...@perlig.de
 mailto:n...@perlig.de wrote:
 
 * Daniel Gruno wrote:
 
 ... 
 
 I'm finding the back/forth here to be a bit more combative than maybe
 needed. Daniel: you asked for feedback. Andre could maybe be more
 constructive and appreciative of your work, but it *is* what you asked for.
I did say I was being terse :) And it was late. Sorry if I sounded too
much like a grumpy cat (or angry pony), it is not my intention to berate
or belittle anyone, but merely to exchange views. Email, like IRC, can
be a terrible purveyor of emotions, things can all to easily be
interpreted as spiteful and combative. I meant no spite or ill intentions.

I want this to be meritocratic and democratic (not utilitarian), in that
we try to compromise so it's the least horrible outcome for as many
people as possible.
 
 Forward movement is good, and I greatly appreciate bringing in Bootstrap
 as a tool for making the site better looking, and more
 layout-responsive. Kudos.
 
 Cheers,
 -g
 

Re: Change of web site layout

[Daniel Gruno]

On 06/16/2014 10:33 AM, Greg Stein wrote:
 I find the carousel to be unhelpful. Left? Right? Is there an ordering?
 Where is the info I need? I actually clicked the arrows several times
 until I realized there were just three bits of info. It is just too
 difficult to see at a glance. Carousels like that (IMO) are best for
 non-task information. If I arrive and am seeking information, then put
 it directly on the page for me to find quickly.
 
 It is only three boxes of information. The look of the (carousel) box is
 nice. Put three of those vertically on the page, and I'd say you're good.
 
I'll give it a try - might take a while to get there, but I'll try :)
I still would like to use a carousel for other things, perhaps we could
start adding some blog posts or tips'n'tricks and use it for that?

Part of what makes me like carousels is that they bring some life to a
page, and our front page, as it is right now, desperately needs some
life. But I also ack that people don't like to have the news in a
carousel, so I'll try adding the news in a bit more traditional fashion,
and then we'll see if we can't use the carousel a bit lower on the page,
but with some 'alternative reading' suggestions.

 Cheers,
 -g
 
 
 
 On Sun, Jun 15, 2014 at 3:55 PM, Daniel Gruno rum...@cord.dk
 mailto:rum...@cord.dk wrote:
 
 Hi there, dev@ people (and docs@ cc'ed),
 
 For some time now, a lot of us from the documentation team have been
 pondering on making our site, well, not so 1990s looking and
 unappealing.
 
 We've had some input from various people over time, and together with my
 own thoughts, I've come up with a new core template that I plan to
 submit to our CMS system if there aren't too many objections.
 
 A mockup front-page featuring this new design can be seen at
 http://httpd.apache.pw/ (please don't start browsing the entire site, IT
 DOES NOT WORK, it needs to be behind our CMS system to be pretty and
 useable).
 
 And yes, this new layout will feature some changes:
 
 - News are placed in a carousel to eliminate the 'wall of text' we
 currently have. RMs will have to get acquainted with how to change the
 news on the site (which shouldn't be difficult if you look at the source
 code, you will still be able to use the CMS to edit it)
 - The menu is now a top bar instead of a side bar
 - Some menu items have been grouped together differently than before
 - The 8 bit feather has been replaced with the 32 bit one.
 - It's not quite as...blue
 
 Now, before half the team starts complaining that this uses HTML5,
 JavaScript or CSS3, please bear in mind that *we are not the intended
 audience*. This is not - and should not be - about what we want, it's
 about what modern (non-lynx) users will find attractive or off-putting
 about a site.
 
 So, I will leave it to you to either love or hate this idea, and if I
 don't hear any (good) arguments against this, I will update the site
 layout in about 72 hours. If, however, someone feels very strongly about
 not changing status quo, I will of course take it to a vote on dev@ (I
 assume docs@ people also follow dev@).
 
 So, throw me some indicative pluses or minuses, or some comments, if you
 care about our site :)
 
 With regards,
 Daniel.
 
 

Change of web site layout

[Daniel Gruno]

Hi there, dev@ people (and docs@ cc'ed),

For some time now, a lot of us from the documentation team have been
pondering on making our site, well, not so 1990s looking and unappealing.

We've had some input from various people over time, and together with my
own thoughts, I've come up with a new core template that I plan to
submit to our CMS system if there aren't too many objections.

A mockup front-page featuring this new design can be seen at
http://httpd.apache.pw/ (please don't start browsing the entire site, IT
DOES NOT WORK, it needs to be behind our CMS system to be pretty and
useable).

And yes, this new layout will feature some changes:

- News are placed in a carousel to eliminate the 'wall of text' we
currently have. RMs will have to get acquainted with how to change the
news on the site (which shouldn't be difficult if you look at the source
code, you will still be able to use the CMS to edit it)
- The menu is now a top bar instead of a side bar
- Some menu items have been grouped together differently than before
- The 8 bit feather has been replaced with the 32 bit one.
- It's not quite as...blue

Now, before half the team starts complaining that this uses HTML5,
JavaScript or CSS3, please bear in mind that *we are not the intended
audience*. This is not - and should not be - about what we want, it's
about what modern (non-lynx) users will find attractive or off-putting
about a site.

So, I will leave it to you to either love or hate this idea, and if I
don't hear any (good) arguments against this, I will update the site
layout in about 72 hours. If, however, someone feels very strongly about
not changing status quo, I will of course take it to a vote on dev@ (I
assume docs@ people also follow dev@).

So, throw me some indicative pluses or minuses, or some comments, if you
care about our site :)

With regards,
Daniel.

Re: Change of web site layout

[Daniel Gruno]

[Disclaimer: I am being terse. It is late here. Or early, as it were.]

On 06/16/2014 01:44 AM, André Malo wrote:
 Hi,
 
 * Daniel Gruno wrote:
 
 Hi there, dev@ people (and docs@ cc'ed),

 For some time now, a lot of us from the documentation team have been
 pondering on making our site, well, not so 1990s looking and unappealing.
 
 +1 at the point.
 

 We've had some input from various people over time, and together with my
 own thoughts, I've come up with a new core template that I plan to
 submit to our CMS system if there aren't too many objections.

 A mockup front-page featuring this new design can be seen at
 http://httpd.apache.pw/ (please don't start browsing the entire site, IT
 DOES NOT WORK, it needs to be behind our CMS system to be pretty and
 useable).

 And yes, this new layout will feature some changes:

 - News are placed in a carousel to eliminate the 'wall of text' we
 currently have. RMs will have to get acquainted with how to change the
 news on the site (which shouldn't be difficult if you look at the source
 code, you will still be able to use the CMS to edit it)
 - The menu is now a top bar instead of a side bar
 - Some menu items have been grouped together differently than before
 - The 8 bit feather has been replaced with the 32 bit one.
 - It's not quite as...blue

 Now, before half the team starts complaining that this uses HTML5,
 JavaScript or CSS3, please bear in mind that *we are not the intended
 audience*. This is not - and should not be - about what we want, it's
 about what modern (non-lynx) users will find attractive or off-putting
 about a site.
 
 That's a killer phrase. User typically find a site attractive, if they find 
 their use cases served (properly). If it looks nice, the better, of course. 
 If it wastes her time looking attractive, but not being helpful, it's just 
 making her angry.
 
 As a user, I'd like to see relevant information. It must be possible to get 
 the relevant information without javascript (yes!) and without random 
 clicking (what should I expect from a non-descriptive arrow-link which 
 feels like an adverstisement?).
I disagree with the use of the word 'must' here, 'should' is a much
nicer word to use when one has only personal preference behind ones
css+noscript combo (identical comment further down, I write in reverse).

 Which means, all maintained releases should be visible at once. That has 
 nothing to do with Apache, that's a simple observation, how people look on 
 software pages.
A counter-observation is that a big wall of text, where everything looks
the same, isn't preferable either. I have tried to counter that, but I
will gladly accept any proposals to add all the (non-EOL) releases to
some form of matrix on the front page. I'm just not sure how to tackle
it yet.

 
 And yes, as an admin I may have only a text browser available if I want to 
 check the current security state of a software *on my server*. Shit 
 happens.
Good thing this proposal works perfectly well with Lynx then.
 
 Anyway, here are some more comments based on a *quick* review. I find the 
 72h timebox way too short for such a change, by the way, especially over a 
 weekend.
It's not _over a weekend_, and I'm not trying to sneak in a change this
big. If I wanted that, I would've JFDI'ed it and taken the flak. But I
also don't want yet another 17(!) years of saying hmm we should do
something and then not doing anything because we're too busy staring at
our own navels. I asked that anyone object if they found something wrong
with a 72h lazy consensus, and you have objected, and I will naturally
take that into account.

We have a web site that screams we don't care anymore!, and that makes
me an angry pony. And sometimes angry ponies use lazy consensus because
it seems like we are only a handful of people who really care enough. I
am glad that you care, that makes another one of us.

 
 (also a screenshot: http://people.apache.org/~nd/shot.png)
That's a matter of tweaking the CSS, although I hadn't imagined anyone
visiting with less than 720p these days, so I hadn't tried what would
happen if someone did. I will correct the styles to also work with very
narrow screens.
 
 - Don't fix the fonts to px size.
 - The maint font (Libertine) is badly readable.
I disagree, but we can probably find a font more suitable (or settle for
Serif if all else fails)
 - the tagline is weirdly placed (see screenshot, made with a current 
   firefox)
Due to the above issue with a very narrow screen.
I have now opted to not fix the top bar to the screen, thus avoiding this.
 - The carousel padding seems strange, too
 - also, it's italic, that looks, like, 80s, sorry (as in: Text processing 
   software on my good old Atari ST :-)
There was one line of italic, just the one. It is now gone.

 - (Maybe the points above are due to freetype, but that's how it is.
 
 - As said, all the technologies are fine, just make sure, it's usable 
   without it. An implementation could

Re: developper/lua.xml

[Daniel Gruno]

On 04/10/2014 03:45 PM, Christophe JAILLET wrote:
 Hi,
 
 manual/developper/lua.xml and co are only in trunk.
 
 Should they be copied in 2.4.x?
 I guess so.
 
 Best regards,
 
 CJ
 
That file is mostly a WIP which has since (for me, personally) been
replaced by modlua.org
I wouldn't just backport it to 2.4, as it's nowhere near being complete.
It even has insert stuff here paragraphs :)

If you're willing to complete those paragraphs, then fine, but I
wouldn't backport it to 2.4 as is.

My $0.02

With regards,
Daniel.

Re: svn commit: r1582858 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/lua/lua_apr.c modules/lua/lua_apr.h modules/lua/lua_request.c modules/lua/lua_request.h

[Daniel Gruno]

On 03/28/2014 09:29 PM, Ruediger Pluem wrote:

 
 Why this check if we already use t-r-pool above :-)?
 
 +ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, t-r, 
 +APLOGNO(02614) mod_lua: Value for '%s' in table '%s' 
 contains newline!,
 +  key, t-n);
 +}
 +apr_table_set(t-t, key, replacement);
 +}
 +else {
 +apr_table_set(t-t, key, val);
  }
 -apr_table_set(t, key, val);
  return 0;
  }
 
 Regards
 
 Rüdiger
 

Brain fart, apologies :)
Since we're already NOT fixing up any table called 'notes', we have no
need to check if t-r is set, since it will only be NULL in the (super
secret, hidden) connection notes table.

Thanks for spotting this!

With regards,
Daniel.