Re: Time for a new libapreq2 release?

[Greg Stein]

You "should" have commit access to svn:repos/asf/httpd/ now. We had to
re-add you to the "committers" list (which also implies receiving future
emails to that list).


On Mon, Aug 28, 2023 at 3:52 PM Joe Schaefer  wrote:

> No objection. Happy to Tag and roll of my account is made available
> somehow.
>
> On Mon, Aug 28, 2023 at 4:50 PM Greg Stein  wrote:
>
>> Your LDAP record is still present [1]. You're still on the PMC of httpd
>> and perl. Commit rights to incubator, sis, subversion. Dunno where httpd
>> went, but as a PMC member of httpd you should have commit. We can fix that.
>>
>> So should we fix this up, so you can walk through a libapreq2 release?
>>
>> Cheers,
>> -g
>> [1] https://whimsy.apache.org/roster/committer/joes
>>
>>
>> On Mon, Aug 28, 2023 at 8:43 AM Joe Schaefer  wrote:
>>
>>> Because my account no longer exists?
>>>
>>> On Mon, Aug 28, 2023 at 1:43 AM Greg Stein  wrote:
>>>
>>>> you're on the PMC. Why don't you do the tag ?
>>>>
>>>> On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer 
>>>> wrote:
>>>>
>>>>> Seems like it’s been a year since the last release, which means it’s
>>>>> time for good people to take another try at releasing something
>>>>> nondefective.
>>>>>
>>>>> Here to help with the quality control this time around.
>>>>> --
>>>>> Joe Schaefer, Ph.D.
>>>>> <https://sunstarsys.com/orion/features>
>>>>> Orion - The Enterprise Jamstack Wiki
>>>>> <https://sunstarsys.com/orion/features>
>>>>> 
>>>>> 954.253.3732 
>>>>>
>>>>>
>>>>> --
>>> Joe Schaefer, Ph.D.
>>> <https://sunstarsys.com/orion/features>
>>> Orion - The Enterprise Jamstack Wiki
>>> <https://sunstarsys.com/orion/features>
>>> 
>>> 954.253.3732 
>>>
>>>
>>> --
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>

Re: Time for a new libapreq2 release?

[Greg Stein]

Your LDAP record is still present [1]. You're still on the PMC of httpd and
perl. Commit rights to incubator, sis, subversion. Dunno where httpd went,
but as a PMC member of httpd you should have commit. We can fix that.

So should we fix this up, so you can walk through a libapreq2 release?

Cheers,
-g
[1] https://whimsy.apache.org/roster/committer/joes


On Mon, Aug 28, 2023 at 8:43 AM Joe Schaefer  wrote:

> Because my account no longer exists?
>
> On Mon, Aug 28, 2023 at 1:43 AM Greg Stein  wrote:
>
>> you're on the PMC. Why don't you do the tag ?
>>
>> On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer  wrote:
>>
>>> Seems like it’s been a year since the last release, which means it’s
>>> time for good people to take another try at releasing something
>>> nondefective.
>>>
>>> Here to help with the quality control this time around.
>>> --
>>> Joe Schaefer, Ph.D.
>>> <https://sunstarsys.com/orion/features>
>>> Orion - The Enterprise Jamstack Wiki
>>> <https://sunstarsys.com/orion/features>
>>> 
>>> 954.253.3732 
>>>
>>>
>>> --
> Joe Schaefer, Ph.D.
> <https://sunstarsys.com/orion/features>
> Orion - The Enterprise Jamstack Wiki
> <https://sunstarsys.com/orion/features>
> 
> 954.253.3732 
>
>
>

Re: Time for a new libapreq2 release?

[Greg Stein]

you're on the PMC. Why don't you do the tag ?

On Sun, Aug 27, 2023 at 4:31 PM Joe Schaefer  wrote:

> Seems like it’s been a year since the last release, which means it’s time
> for good people to take another try at releasing something nondefective.
>
> Here to help with the quality control this time around.
> --
> Joe Schaefer, Ph.D.
> 
> Orion - The Enterprise Jamstack Wiki
> 
> 
> 954.253.3732 
>
>
>

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

[Greg Stein]

On Wed, May 10, 2023 at 5:18 AM Stefan Sperling  wrote:
>...

> I did have some hope that we would see individual self-motivated
> contributors
> arriving via various ASF projects because they are all using SVN every day
> on svn.apache.org, are programmers, might have itches to scratch, already
> have
> commit access to ^/subversion, and there is some sense of shared ownership
> across the ASF community. I was reminded of all this by Graham's remark.
> It's the lack of such interactions that I find disappointing in retrospect.
> There certainly have been some, but relatively few.
>

IMO, it is because Subversion is successful.

It just works. Zero friction. It doesn't cause developers a headache or an
"itch to scratch".

One doesn't think to improve their dishwasher. It just works. Why change
your hammer? It works.

I believe that Subversion hit its goal, and then some. I believe that is
why the *use* of Subversion did not lead to a desire to work/fix/change
Subversion.

Cheers,
-g

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

[Greg Stein]

On Mon, May 8, 2023 at 9:08 AM Stefan Sperling  wrote:
>...

> If the ASF at large was confident in SVN as a technology then our current
> reality would look quite different. The Subversion project never managed
> to grow its developer base by becoming part of the ASF. We've mostly seen
>

That is simply untrue.

Case in point: WANdisco did not materially contribute to svn *until* the
project left the CollabNet umbrella. At that point, WD put several
full-time developers onto the project, and ramped up their project plans.
This is a specific *fact* directly from my conversations with the CEO, over
the phone and in-person at their offices in Sheffield. And WANdisco offered
many developers', over many years, with very significant and important
contributions.

The ASF is completely confident in svn, and basically 99% of our corporate
records, and some of our key workflows (eg. account requests, TLP
graduation, ICLA recording) is all based on Apache Subversion. Also a fact.
And zero plans to change that. Git is not envisioned to replace any of that.

Your implication that the Foundation was somehow required to grow the svn
community is misplaced. That is not its purpose. The Apache Subversion
community is responsible for growing itself. In 2011, the Board of
Directors specifically declined to assist a TLP with its community (*way*
larger than svn) because that is not the purpose of the Foundation. We do
not want some people "over there" on the Foundation/administrative side
interfering with the technical operation, and the community dynamics of one
of the communities. Or, even worse, to *pick* which communities get
assistance, while others do not. No winners. No losers. (clearly: I am
upset by your implication that you've been let down; the true answer is
missing a step on the Foundation's role)

As Daniel notes else-thread, the suggestion is not git vs. svn. It is
entirely about "Do we want the tools offered by GitHub, to be made
available to the Apache HTTPD community?"

I'm an svn partisan, but I also appreciate GitHub for its utility. I
voted +1 to move, for that reason only. Hands-down, I'd -1 a move to git.
It was only GitHub that changed my opinion on this issue.

Cheers,
-g

what does svn/github integration mean? (was:: [VOTE] Switch read/write repository...)

[Greg Stein]

On Mon, May 8, 2023 at 4:29 AM Graham Leggett via dev 
wrote:

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

> > [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.
>

What do you mean by "integration"? GitHub is dropping their svn proxy. How
do you propose that svn should integrate with GitHub? What does that mean?

And what are these "our own projects" that you're expressing a lack of
confidence in? All 200+ ASF projects?

Cheers,
-g

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

[Greg Stein]

I might suggest another day or two because of the weekend and because it is
so high-impact. Maybe an extra post to private@ in case some PMC members
aren't tracking dev@ very closely.


On Mon, May 8, 2023 at 1:42 AM 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.
> >
>
> This vote is now open for about 96 hours and has numerous votes. Anyone
> opposed if I call it closed and tally the results?
>
> Regards
>
> Rüdiger
>

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

[Greg Stein]

On Fri, May 5, 2023 at 3:19 AM Dennis Clarke  wrote:

>
> > Everybody says git is decentralized, so why are you even asking this
> > question? Can't you just use any git repository, anywhere? ;-)
>
> Github is microsoft and you can bet they will break things. It is only a
> matter of time with them.
>

That is a fine opinion to hold. Many people (including myself) would
disagree with your opinion.

The voting so far appears to show that people are not concerned with the
hypothetical "they will break things". I would suggest there are no
comparative historical precedents, so the votes are not reflective of that
... opinion.

Cheers,
-g

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

[Greg Stein]

On Fri, May 5, 2023 at 2:12 AM Dennis Clarke  wrote:
>...

>  Why the assumption of Microsoft github?  There is no reason to
> migrate to a git service such as Microsoft github when sourcehut works
> just fine as does a private git repo provided by Apache FSF itself.
>

Because the Apache Instructure Team has constructed a lot of tooling around
GitHub, to support git-based development at the Foundation. We
maintain/synchronize our own copy of the git repository, mailing lists and
commit emails are provided, LDAP authz groups are mapped to GitHub teams,
we have GitHub Actions available, and more. GitHub is fully-supported and
backed by Microsoft (and we have direct contact with them); compare with
sourcehut, quote: "Notice: sr.ht is currently in alpha, and the quality of
the service may reflect that."

Everybody says git is decentralized, so why are you even asking this
question? Can't you just use any git repository, anywhere? ;-)

Cheers,
-g

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

[Greg Stein]

+1 for switching to GitHub (which implies a switch to git). So:

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


On Thu, May 4, 2023 at 3: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, but I don't
> want to work with Github and I will only work with
>  what gitbox.apache.org offers.
> [ ]: Leave everything as is.
>
>
> Regards
>
> Rüdiger
>

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

[Greg Stein]

On Tue, Apr 25, 2023 at 1:45 AM 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.
>

Today 0% of httpd developers can use those features of GitHub. Switching
allows (say:) 90% of our developers, and potentially some downstream
developers and users who are familiar with "how to work with upstream code
providers, who use GitHub".

Stick with 0%, or go with "more than 0%" ?

As noted elsewhere, the GitHub Subversion support has been *sunsetted* and
will go away. That should be kept in mind. People will not be able to stick
to their svn client, whether readonly or read/write.

JoeS notes elsewhere that the git support provided by Infra is
strongly-linked to GitHub. From the Foundation's standpoint, the amount of
utility is provided is vastly higher than any business risk associated with
GitHub going dark or pulling their support for our Foundation. We have all
our data, all the provenance, and everything we need, should that day ever
arise. But it should not concern anybody in the community to create a
reliance/dependency upon GitHub.

Down-thread, Giovanni asks about security patch handling. We can continue
to use repos/private/pmc/httpd/ for that. That area will not go away. If
people want to go "all git", then Infra can provide projects with a single,
private repository that would function similarly.

IMO, I definitely think svn is a superior version control system to git. It
is much more approachable and easy to use, compared to git. I helped to
build svn, yet I use git daily; this isn't knee-jerk svn partisanship; svn
is simply better/easier. But *GitHub* is a fabulous tool. I will take the
inferior VCS in order to access the GitHub feature set. It is unfortunate
that such a site never got built for svn, but it is what it is. GitHub >
svn > git.

Cheers,
-g

Re: [libapreq2] nits to pick about the patches to util.c over the past few years

[Greg Stein]

F/OSS is not about telling others how to write their code, Joe. You know
this. And it *definitely* is not about demanding they spend *their* time to
fix your pet issues.

If you have a problem with the code, then supply a fix. Your dozen emails
are not fixing anything, and are certainly not endearing anybody to help
you. Be nice, if you want help.

-g


On Sat, Oct 29, 2022 at 11:11 AM Joe Schaefer  wrote:

> ...fell apart when Max asked you to release his patch to my screwup with
> the NPE, and instead of cutting a release
> with just that patch applied, you began the tragic process of dorking
> around with apreq_header_attribute() as well.
>
> Just pull all those hacks out of apreq/trunk, and release exactly what Max
> told you to release, and you will be good for another quiet decade of happy
> libapreq2 users.
>
> If you do not take this advice, at least for your own personal
> reputations, stop hacking the logic and  start writing regression tests.
>  An internet-grade mfd parser is only as good as its weakest link, and I
> just spent the past day telling you where that is.
>
> On Sat, Oct 29, 2022 at 12:06 PM Joe Schaefer  wrote:
>
>> All we need to do at this point is remember the basics of how to cut a
>> security bugfix release.  Everything in libapreq
>>
>> On Fri, Oct 28, 2022 at 3:04 PM  wrote:
>>
>>> Long time fan, not a first time caller.
>>>
>>>
>>>
>>> Libapreq2 was intended to be a safe,fast, standards compliant library-
>>> primarily **safe** before all other priorities.  Some of the work going
>>> on lately in util.c is starting to undermine that prime directive, so I’d
>>> like to better understand why these changes are happening, and why they are
>>> snowballing into a less functional, less secure software product that is
>>> driving up my support costs on CPAN.
>>>
>>>
>>>
>>> For instance, this revision 1867789 is a pure pessimization:  it trades
>>> userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.
>>> Just churn.
>>>
>>>
>>>
>>> Everything in the crufty, old apreq_header_attribute code I wrote was
>>> completely tossed and reimplemented.  Why?  We’re just racking up CVE’s,
>>> people are disabling the mfd parser altogether, and it no longer support
>>> common use cases that people now complain about because it supported cases
>>> in the wild that the new work does not.
>>>
>>>
>>>
>>> With the latest code coming out of p5p for Perl, there’s a whole new
>>> reason for excitement in httpd-land: the mod_perl2 + mpm_event combination
>>> is rock solid and screaming fast with HTTP/2.  The only reason I resubbed
>>> here is in the hopes of some synergy retaking these perl-related projects,
>>> since mod_perl2 is the only game in town for embedded interpreters in
>>> httpd2 (and no, lua is not the answer, it’s not thread safe either).
>>>
>>>
>>>
>>>
>>>
>>> Joe Schaefer, Ph.D.
>>>
>>> 
>>>
>>> 954.253.3732 
>>>
>>> SunStar Systems CMS  *- The Original
>>> Markdown JAM Stack**™*
>>>
>>>
>>>
>>
>>
>> --
>> Joe Schaefer, Ph.D.
>> We only build what you need built.
>> 
>> 954.253.3732 
>>
>>
>>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> 
> 954.253.3732 
>
>
>

Re: svn commit: r1904638 - in /httpd/httpd/trunk: changes-entries/DAVLockDiscovery.txt modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h modules/dav/main/props.c

[Greg Stein]

On Thu, Oct 27, 2022 at 8:22 AM Emmanuel Dreyfus  wrote:

> On Thu, Oct 27, 2022 at 01:58:58AM -0500, Greg Stein wrote:
> > With that said, I'm not a fan of [DAV or svn] locks. Anything that can be
> > done to avoid a workflow that encompasses locks would be ideal.
>
> For DAV filesystem, we cannot spare locks when clients use LOCK/UNLOCK
> methods. Lock discovery by PROPFIND is another story, I cannot see
> a use case for that.


Agree.


> If you want to see less locks, then you must be great fan of my
> DAVLockDiscovery contribution, especially now it has been updated
> as a flag directive.


Yeup!


> Any chance we get it into 2.4 branch?
>

I'll let others throw in on this. I haven't worked on httpd for quite a
long time.

Cheers,
-g

Re: svn commit: r1904638 - in /httpd/httpd/trunk: changes-entries/DAVLockDiscovery.txt modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h modules/dav/main/props.c

[Greg Stein]

On Wed, Oct 26, 2022 at 1:59 PM Emmanuel Dreyfus  wrote:

> On Tue, Oct 18, 2022 at 05:03:48PM +, Emmanuel Dreyfus wrote:
> > dbm is fast once you have it open. mod_dav_fs opens DAVLockDB on each
> > HTTP request, then it acquire a filesystem level lock on it. This is
> > where contenton occurs.
>

Gotcha. Yes, that makes total sense.


> I have been thinking about how Apache could open DAVLockDB once, instead
> of for each HTTP request. The workers should share a file descriptor
> on the file, and a mutex to avoid concurent access.
>
> That does not fit well with the prefork model. Opending DAVLockDB
> and creating the mutex (a sysV mutex?) should be done in the master
> process. Should it be done when processing the configuration directive?
>
> We would also need to take care of closing the previous file descriptor on
> reloads.
>

That's gonna get very tricky across the various MPMs. dbm wasn't really
designed for this.

When I wrote mod_dav way back when, SQLite was not available. That is where
I'd go today for the lock database (and properties). It handles
multi-process, multi-thread, and is very efficient. If you are sufficiently
motivated, that would be an excellent path forward.

With that said, I'm not a fan of [DAV or svn] locks. Anything that can be
done to avoid a workflow that encompasses locks would be ideal.

Cheers,
-g

Re: svn commit: r1904638 - in /httpd/httpd/trunk: changes-entries/DAVLockDiscovery.txt modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h modules/dav/main/props.c

[Greg Stein]

Did you run any tests to observe the alleged contention?

The dbm database is very fast. I'd be surprised that contention occurs in
any typical workload.

Cheers,
-g


On Mon, Oct 17, 2022 at 4:48 AM  wrote:

> Author: ylavic
> Date: Mon Oct 17 09:48:11 2022
> New Revision: 1904638
>
> URL: http://svn.apache.org/viewvc?rev=1904638=rev
> Log:
> mod_dav: Allow to disable lock discovery via an DAVLockDiscovery
> expression.
>
> mod_dav-fs scales badly when a few clients run PROPFIND requests to
> discover
> directory content. Each PROPFIND involves lockdiscovery, which in turn
> waits
> for a locked access to the file containing the lock database. Performances
> quickly drop because of lock contention on this file.
>
> Add a DAVLockDiscovery configuration directive that allows lockdiscovery
> to be
> disabled. Its argument is an Apache expression so that flexible
> configuration
> are possible (per-request).
>
> When lock discovery is disabled, an empty lockdiscovery property is
> returned on
> POPRFIND methods, just like if no lock was set on the object. That should
> cause
> no regression, since a client cannot rely on lockdiscovery to decide when a
> file should be accessed, the LOCK methood must be used.
>
> If DAVLockDiscovery is not specified, the behavior is unchanged.
>
>
> PR 66313.
> Submitted by: Emmanuel Dreyfus 
> Reviewed by: ylavic
>
>
> Added:
> httpd/httpd/trunk/changes-entries/DAVLockDiscovery.txt
> Modified:
> httpd/httpd/trunk/modules/dav/main/mod_dav.c
> httpd/httpd/trunk/modules/dav/main/mod_dav.h
> httpd/httpd/trunk/modules/dav/main/props.c
>
> Added: httpd/httpd/trunk/changes-entries/DAVLockDiscovery.txt
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/changes-entries/DAVLockDiscovery.txt?rev=1904638=auto
>
> ==
> --- httpd/httpd/trunk/changes-entries/DAVLockDiscovery.txt (added)
> +++ httpd/httpd/trunk/changes-entries/DAVLockDiscovery.txt Mon Oct 17
> 09:48:11 2022
> @@ -0,0 +1,2 @@
> +  *) mod_dav: Allow to disable lock discovery via an DAVLockDiscovery
> + expression (per-request). PR 66313. [Emmanuel Dreyfus  netbsd.org>]
>
> Modified: httpd/httpd/trunk/modules/dav/main/mod_dav.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/mod_dav.c?rev=1904638=1904637=1904638=diff
>
> ==
> --- httpd/httpd/trunk/modules/dav/main/mod_dav.c (original)
> +++ httpd/httpd/trunk/modules/dav/main/mod_dav.c Mon Oct 17 09:48:11 2022
> @@ -83,6 +83,7 @@ typedef struct {
>  const char *dir;
>  int locktimeout;
>  int allow_depthinfinity;
> +ap_expr_info_t *allow_lockdiscovery;
>
>  } dav_dir_conf;
>
> @@ -203,6 +204,8 @@ static void *dav_merge_dir_config(apr_po
>  newconf->dir = DAV_INHERIT_VALUE(parent, child, dir);
>  newconf->allow_depthinfinity = DAV_INHERIT_VALUE(parent, child,
>   allow_depthinfinity);
> +newconf->allow_lockdiscovery = DAV_INHERIT_VALUE(parent, child,
> + allow_lockdiscovery);
>
>  return newconf;
>  }
> @@ -301,6 +304,30 @@ static const char *dav_cmd_davdepthinfin
>  }
>
>  /*
> + * Command handler for the DAVLockDiscovery directive, which is TAKE1.
> + */
> +static const char *dav_cmd_davlockdiscovery(cmd_parms *cmd, void *config,
> +const char *arg)
> +{
> +dav_dir_conf *conf = (dav_dir_conf *)config;
> +
> +if (strncasecmp(arg, "expr=", 5) == 0) {
> +const char *err;
> +if ((arg[5] == '\0'))
> +return "missing condition";
> +conf->allow_lockdiscovery = ap_expr_parse_cmd(cmd, [5],
> +
> AP_EXPR_FLAG_DONT_VARY,
> +  , NULL);
> +if (err)
> +return err;
> +} else {
> +return "error in condition clause";
> +}
> +
> +return NULL;
> +}
> +
> +/*
>   * Command handler for DAVMinTimeout directive, which is TAKE1
>   */
>  static const char *dav_cmd_davmintimeout(cmd_parms *cmd, void *config,
> @@ -1450,7 +1477,7 @@ static dav_error *dav_gen_supported_live
>  }
>
>  /* open the property database (readonly) for the resource */
> -if ((err = dav_open_propdb(r, lockdb, resource, 1, NULL,
> +if ((err = dav_open_propdb(r, lockdb, resource, DAV_PROPDB_RO, NULL,
> )) != NULL) {
>  if (lockdb != NULL)
>  (*lockdb->hooks->close_lockdb)(lockdb);
> @@ -2045,6 +2072,8 @@ static void dav_cache_badprops(dav_walke
>  static dav_error * dav_propfind_walker(dav_walk_resource *wres, int
> calltype)
>  {
>  dav_walker_ctx *ctx = wres->walk_ctx;
> +dav_dir_conf *conf;
> +int flags = DAV_PROPDB_RO;
>  dav_error *err;
>  dav_propdb *propdb;
>  dav_get_props_result propstats = { 0 };
> @@ -2068,6 +2097,20 @@ 

Re: announce mails

[Greg Stein]

The mirror system is no longer used. Most downloads are processed through a
CDN instead. European downloaders will tend to hit downloads.apache.org
which is "instantly" updated once a release artifact is committed to the
svn distribution repository.

rsync.apache should be just as instant. If not, then please file an INFRA
ticket.

Cheers,
-g


On Mon, Dec 20, 2021 at 7:26 PM Nick Edwards 
wrote:

> Why would the release system initiate an announce when the mirrors are not
> up to date, they cant be, since rsync.apache still lists 2.4.51 as latest,
> the process is to allow time for mirrors to get the package before
> announcing it
>
>
> On Mon, Dec 20, 2021 at 7:53 PM Stefan Eissing  wrote:
>
>> The mailings to announce lists continue to bother me. The release
>> announcement is the the moderation queue (hopefully) and the cveprocess
>> mails go right through to the list. This is not the order I prefer.
>>
>> I am holden back the send about the second CVE until I see the release
>> announcement winked through.
>>
>> - Stefan
>
>

Re: mod_tls as experimental module?

[Greg Stein]

On Fri, Nov 26, 2021 at 3:49 AM ste...@eissing.org 
wrote:
>...

> Additionally, we need to clarify with ASF and ISRG if this needs some sort
> of
> paperwork. Since the ISRG repository uses the Apache license, in my naive
> world
> view, this should be quite an informal process. But I do not really know.
>

We have numerous copies of permissive-licensed code within our
repositories, and that is fine as long as no such code is "more restrictive
than the ALv2". Since the existing mod_tls is provided under ALv2, then no
additional paperwork should be required. We are merely using that code
under the license provided.

The real question is whether the files to be imported into our repository
have headers that specify copyright held by others. For that, we need to
get the copyright owners' approval to replace that with our standard header.
https://www.apache.org/legal/src-headers.html
(if we want to change them; we could simply copy from upstream, or change
if the locus of development is our repository)

There is likely some other page talking about permission to switch out the
copyright header, but I don't have that link handy.

Cheers,
-g

Re: mod_tls as experimental module?

[Greg Stein]

On Thu, Nov 25, 2021 at 3:42 AM ste...@eissing.org 
wrote:
>...

> In its development, the arrival of mod_tls has caused changes in our
> server core. Not in any way related to Rust itself. But we added the
> capability to have more than one SSL/TLS provider in our server. So people
> can use whatever fits best for the parts they need it.
>
> Future improvements in this area would be done easiest, if mod_tls is a
> module in our source base next to mod_ssl. API dependencies are managed
> better if we release enhanced versions together. I see no benefit for
> anyone involved in making it a separate Apache httpd subproject. It has a
> home on github with all its infrastructure.
>

+1 on including mod_tls (or mod_rustls) in our tree as experimental. That
is *precisely* why we have the experimental label. Historically, the
concept of "subproject" has been ... suboptimal, to put it nicely.

The changes to the core can/should be made regardless of adoption of this
module.

Cheers,
-g

Re: Download page appears to be broken

[Greg Stein]

On Sun, Oct 31, 2021 at 6:13 PM Noel Butler  wrote:

> On 01/11/2021 06:38, Gillis J. de Nijs wrote:
>
> There seems to be a problem with the correct rendering of the mirrors on
> that page.  It doesn't work for me, either.
>
>
>
> Mirrors are no more, ASF now uses a CDN, this change is very recent -
> weeks, so might be some teething issues on website code still
>
Not teething. It all works fine. The OP just linked to the template, not
the CGI that constructs a download link for you. ... ie. wrong URL.
httpd.apache.org has the correct URL (of course)

Cheers,
-g

Re: sending announcement mail

[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)

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: svn commit: r1891407 - /httpd/site/trunk/content/docs-project/contribute.mdtext

[Greg Stein]

On Tue, Jul 13, 2021 at 7:22 AM Ruediger Pluem  wrote:

> On 7/13/21 2:12 PM, Rich Bowen wrote:
> > On 7/9/21 4:10 PM, Ruediger Pluem wrote:
>
>...

> >> See also:https://infra.apache.org/asf-pelican.html
> >
> > I see. I misunderstood. I thought that Github was just a mirror.
>
> For all stuff but for httpd-site it is a mirror and svn is canonical.
> httpd-site is now natively on Github since the site migration.
>

The primary benefit here is that you can visit github.com and use the
"pencil" in the upper right when viewing a .md file, to edit that specific
page. The preview displays it in "github flavored markdown", and the
Pelican process uses the exact same C library to render final html pages.
(the CSS will be different, of course) ... this provides a pretty simple
process for editing/previewing the httpd website.

Cheers,
-g

ps. note that we also synchronize the git repo back/forth to
gitbox.apache.org and allow people to commit there, should they disagree
with establishing a GitHub account.

Re: migration of the HTTPD project website

[Greg Stein]

On Wed, Jun 30, 2021 at 1:50 AM Ruediger Pluem  wrote:
>...

> I guess he talks about
>
> # Get the tooling
> svn co https://svn.apache.org/repos/asf/httpd/site/trunk/tools tools
>
> I think we should find a new location for this as this is not really site
> related.
> How about
>
> https://svn.apache.org/repos/asf/httpd/dev-tools/trunk
>
> (svn mv https://svn.apache.org/repos/asf/httpd/site/trunk/tools
> https://svn.apache.org/repos/asf/httpd/dev-tools/trunk)
>

If we don't intend to make *releases* of these tools, then I recommend
dropping "trunk", and just call it .../httpd/dev-tools/

IMO, trunk/tags/branches ("TTB") should only be used in relation to
artifacts that will be packaged/released by the Foundation.

Cheers,
-g

Re: where do we want to send website bot notices?

[Greg Stein]

I think any commit, including to the website, should go to commits@httpd
(which should be the proper name for cvs@ which is stoopid archaic).

Cheers,
-g


On Fri, Jun 25, 2021, 17:50 Roy T. Fielding  wrote:

> I was about to update the site config so that it wouldn't send notices
> to dev, but I don't know whether they should instead go to cvs, docs, or
> a new list (like notices at httpd).  Any opinions?
>
> Roy
>

Re: svn commit: r1879889 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/dav/main/mod_dav.h modules/dav/main/props.c

[Greg Stein]

You're already changing the API ... why not simply introduce
insert_prop_v2() with the appropriate parameters? This concept of "pass
parameters via the pool" is very disturbing.

Cheers,
-g

On Wed, Jul 15, 2020 at 8:56 AM  wrote:

> Author: minfrin
> Date: Wed Jul 15 13:56:55 2020
> New Revision: 1879889
>
> URL: http://svn.apache.org/viewvc?rev=1879889=rev
> Log:
> mod_dav: Some DAV extensions, like CalDAV, specify both document
> elements and property elements that need to be taken into account
> when generating a property. The document element and property element
> are made available in the dav_liveprop_elem structure under the
> DAV_PROP_ELEMENT key in the resource pool.
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/include/ap_mmn.h
> httpd/httpd/trunk/modules/dav/main/mod_dav.h
> httpd/httpd/trunk/modules/dav/main/props.c
>
> Modified: httpd/httpd/trunk/CHANGES
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1879889=1879888=1879889=diff
>
> ==
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Wed Jul 15 13:56:55 2020
> @@ -1,6 +1,12 @@
>   -*- coding:
> utf-8 -*-
>  Changes with Apache 2.5.1
>
> +  *) mod_dav: Some DAV extensions, like CalDAV, specify both document
> + elements and property elements that need to be taken into account
> + when generating a property. The document element and property element
> + are made available in the dav_liveprop_elem structure under the
> + DAV_PROP_ELEMENT key in the resource pool. [Graham Leggett]
> +
>*) mod_dav: Add utility functions dav_validate_root_ns(),
>   dav_find_child_ns(), dav_find_next_ns(), dav_find_attr_ns() and
>   dav_find_attr() so that other modules get to play too.
>
> Modified: httpd/httpd/trunk/include/ap_mmn.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1879889=1879888=1879889=diff
>
> ==
> --- httpd/httpd/trunk/include/ap_mmn.h (original)
> +++ httpd/httpd/trunk/include/ap_mmn.h Wed Jul 15 13:56:55 2020
> @@ -657,6 +657,8 @@
>   * 20200705.1 (2.5.1-dev)  Add dav_validate_root_ns(),
> dav_find_child_ns(),
>   * dav_find_next_ns(), dav_find_attr_ns() and
>   * dav_find_attr().
> + * 20200705.2 (2.5.1-dev)  Add dav_liveprop_elem structure and
> + * DAV_PROP_ELEMENT key.
>   */
>
>  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
> @@ -664,7 +666,7 @@
>  #ifndef MODULE_MAGIC_NUMBER_MAJOR
>  #define MODULE_MAGIC_NUMBER_MAJOR 20200705
>  #endif
> -#define MODULE_MAGIC_NUMBER_MINOR 1 /* 0...n */
> +#define MODULE_MAGIC_NUMBER_MINOR 2 /* 0...n */
>
>  /**
>   * Determine if the server's current MODULE_MAGIC_NUMBER is at least a
>
> Modified: httpd/httpd/trunk/modules/dav/main/mod_dav.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/mod_dav.h?rev=1879889=1879888=1879889=diff
>
> ==
> --- httpd/httpd/trunk/modules/dav/main/mod_dav.h (original)
> +++ httpd/httpd/trunk/modules/dav/main/mod_dav.h Wed Jul 15 13:56:55 2020
> @@ -913,6 +913,14 @@ struct dav_hooks_liveprop
>  ** property, and does not want it handled as a dead property, it
> should
>  ** return DAV_PROP_INSERT_NOTSUPP.
>  **
> +** Some DAV extensions, like CalDAV, specify both document elements
> +** and property elements that need to be taken into account when
> +** generating a property. The document element and property element
> +** are made available in the dav_liveprop_elem structure under the
> +** DAV_PROP_ELEMENT key in the resource pool, accessible as follows:
> +**
> +** apr_pool_userdata_get(, DAV_PROP_ELEMENT, resource->pool);
> +**
>  ** Returns one of DAV_PROP_INSERT_* based on what happened.
>  **
>  ** ### we may need more context... ie. the lock database
> @@ -1061,6 +1069,20 @@ DAV_DECLARE(void) dav_add_all_liveprop_x
>   apr_text_header *phdr);
>
>  /*
> + ** When calling insert_prop(), the request element is associated with
> + ** the pool userdata attached to the resource. Access as follows:
> + **
> + ** apr_pool_userdata_get(, DAV_PROP_ELEMENT, resource->pool);
> + **
> + */
> +#define DAV_PROP_ELEMENT "mod_dav-element"
> +
> +typedef struct {
> +const apr_xml_doc *doc;
> +const apr_xml_elem *elem;
> +} dav_liveprop_elem;
> +
> +/*
>  ** The following three functions are part of mod_dav's internal handling
>  ** for the core WebDAV properties. They are not part of mod_dav's API.
>  */
>
> Modified: httpd/httpd/trunk/modules/dav/main/props.c
> URL:
> 

Re: svn commit: r1879888 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/dav/main/mod_dav.h modules/dav/main/util.c

[Greg Stein]

Seems these helper functions would be a better fit within apr_xml, rather
than httpd.


On Wed, Jul 15, 2020 at 8:16 AM  wrote:

> Author: minfrin
> Date: Wed Jul 15 13:16:19 2020
> New Revision: 1879888
>
> URL: http://svn.apache.org/viewvc?rev=1879888=rev
> Log:
> mod_dav: Add utility functions dav_validate_root_ns(),
> dav_find_child_ns(), dav_find_next_ns(), dav_find_attr_ns() and
> dav_find_attr() so that other modules get to play too.
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/include/ap_mmn.h
> httpd/httpd/trunk/modules/dav/main/mod_dav.h
> httpd/httpd/trunk/modules/dav/main/util.c
>
> Modified: httpd/httpd/trunk/CHANGES
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1879888=1879887=1879888=diff
>
> ==
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Wed Jul 15 13:16:19 2020
> @@ -1,6 +1,10 @@
>   -*- coding:
> utf-8 -*-
>  Changes with Apache 2.5.1
>
> +  *) mod_dav: Add utility functions dav_validate_root_ns(),
> + dav_find_child_ns(), dav_find_next_ns(), dav_find_attr_ns() and
> + dav_find_attr() so that other modules get to play too.
> + [Graham Leggett]
>
>*) mod_http2:
>   Fixes :
>
> Modified: httpd/httpd/trunk/include/ap_mmn.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1879888=1879887=1879888=diff
>
> ==
> --- httpd/httpd/trunk/include/ap_mmn.h (original)
> +++ httpd/httpd/trunk/include/ap_mmn.h Wed Jul 15 13:16:19 2020
> @@ -654,6 +654,9 @@
>   * 20200703.0 (2.5.1-dev)  Remove ap_md5digest(), ap_md5contextTo64(),
>   * ContentDigest directive.
>   * 20200705.0 (2.5.1-dev)  Update method_precondition hook.
> + * 20200705.1 (2.5.1-dev)  Add dav_validate_root_ns(),
> dav_find_child_ns(),
> + * dav_find_next_ns(), dav_find_attr_ns() and
> + * dav_find_attr().
>   */
>
>  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
> @@ -661,7 +664,7 @@
>  #ifndef MODULE_MAGIC_NUMBER_MAJOR
>  #define MODULE_MAGIC_NUMBER_MAJOR 20200705
>  #endif
> -#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */
> +#define MODULE_MAGIC_NUMBER_MINOR 1 /* 0...n */
>
>  /**
>   * Determine if the server's current MODULE_MAGIC_NUMBER is at least a
>
> Modified: httpd/httpd/trunk/modules/dav/main/mod_dav.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/mod_dav.h?rev=1879888=1879887=1879888=diff
>
> ==
> --- httpd/httpd/trunk/modules/dav/main/mod_dav.h (original)
> +++ httpd/httpd/trunk/modules/dav/main/mod_dav.h Wed Jul 15 13:16:19 2020
> @@ -583,8 +583,22 @@ DAV_DECLARE(int) dav_get_depth(request_r
>
>  DAV_DECLARE(int) dav_validate_root(const apr_xml_doc *doc,
> const char *tagname);
> +DAV_DECLARE(int) dav_validate_root_ns(const apr_xml_doc *doc,
> +  int ns, const char *tagname);
>  DAV_DECLARE(apr_xml_elem *) dav_find_child(const apr_xml_elem *elem,
> const char *tagname);
> +DAV_DECLARE(apr_xml_elem *) dav_find_child_ns(const apr_xml_elem *elem,
> +  int ns, const char
> *tagname);
> +DAV_DECLARE(apr_xml_elem *) dav_find_next_ns(const apr_xml_elem *elem,
> + int ns, const char *tagname);
> +
> +/* find and return the attribute with a name in the given namespace */
> +DAV_DECLARE(apr_xml_attr *) dav_find_attr_ns(const apr_xml_elem *elem,
> + int ns, const char
> *attrname);
> +
> +/* find and return the attribute with a given DAV: tagname */
> +DAV_DECLARE(apr_xml_attr *) dav_find_attr(const apr_xml_elem *elem,
> +  const char *attrname);
>
>  /* gather up all the CDATA into a single string */
>  DAV_DECLARE(const char *) dav_xml_get_cdata(const apr_xml_elem *elem,
> apr_pool_t *pool,
>
> Modified: httpd/httpd/trunk/modules/dav/main/util.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/util.c?rev=1879888=1879887=1879888=diff
>
> ==
> --- httpd/httpd/trunk/modules/dav/main/util.c (original)
> +++ httpd/httpd/trunk/modules/dav/main/util.c Wed Jul 15 13:16:19 2020
> @@ -316,26 +316,71 @@ DAV_DECLARE(dav_lookup_result) dav_looku
>  */
>
>  /* validate that the root element uses a given DAV: tagname (TRUE==valid)
> */
> -DAV_DECLARE(int) dav_validate_root(const apr_xml_doc *doc,
> -   const char *tagname)
> 

Re: svn commit: r1879306 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/dav/main/mod_dav.c modules/dav/main/mod_dav.h

[Greg Stein]

Hey Graham ... what's the goal with exposing these things? (this rev, and
prior) ... I don't see any emails describing "why". Generally, it would be
"shrug" ... but you're changing the MMN, and I don't see any discussion on
why/goal.

Thanks,
-g


On Sun, Jun 28, 2020 at 8:17 AM  wrote:

> Author: minfrin
> Date: Sun Jun 28 13:17:26 2020
> New Revision: 1879306
>
> URL: http://svn.apache.org/viewvc?rev=1879306=rev
> Log:
> Add hooks deliver_report and gather_reports to mod_dav.h. Allows other
> modules apart from versioning implementations to handle the REPORT method.
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/include/ap_mmn.h
> httpd/httpd/trunk/modules/dav/main/mod_dav.c
> httpd/httpd/trunk/modules/dav/main/mod_dav.h
>
> Modified: httpd/httpd/trunk/CHANGES
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1879306=1879305=1879306=diff
>
> ==
> --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Sun Jun 28 13:17:26 2020
> @@ -1,6 +1,10 @@
>   -*- coding:
> utf-8 -*-
>  Changes with Apache 2.5.1
>
> +  *) Add hooks deliver_report and gather_reports to mod_dav.h. Allows
> other
> + modules apart from versioning implementations to handle the REPORT
> method.
> + [Graham Leggett]
> +
>*) Add dav_get_provider(), dav_open_lockdb() and dav_close_lockdb()
> mod_dav.h.
>   [Graham Leggett]
>
>
> Modified: httpd/httpd/trunk/include/ap_mmn.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/ap_mmn.h?rev=1879306=1879305=1879306=diff
>
> ==
> --- httpd/httpd/trunk/include/ap_mmn.h (original)
> +++ httpd/httpd/trunk/include/ap_mmn.h Sun Jun 28 13:17:26 2020
> @@ -643,6 +643,8 @@
>   * Add bnotes to request_rec.
>   * 20200420.8 (2.5.1-dev)  Add dav_get_provider(), dav_open_lockdb() and
>   * dav_close_lockdb() mod_dav.h.
> + * 20200420.9 (2.5.1-dev)  Add hooks deliver_report and gather_reports to
> + * mod_dav.h.
>   */
>
>  #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
> @@ -650,7 +652,7 @@
>  #ifndef MODULE_MAGIC_NUMBER_MAJOR
>  #define MODULE_MAGIC_NUMBER_MAJOR 20200420
>  #endif
> -#define MODULE_MAGIC_NUMBER_MINOR 8/* 0...n */
> +#define MODULE_MAGIC_NUMBER_MINOR 9/* 0...n */
>
>  /**
>   * Determine if the server's current MODULE_MAGIC_NUMBER is at least a
>
> Modified: httpd/httpd/trunk/modules/dav/main/mod_dav.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/mod_dav.c?rev=1879306=1879305=1879306=diff
>
> ==
> --- httpd/httpd/trunk/modules/dav/main/mod_dav.c (original)
> +++ httpd/httpd/trunk/modules/dav/main/mod_dav.c Sun Jun 28 13:17:26 2020
> @@ -5005,6 +5005,8 @@ APR_HOOK_STRUCT(
>  APR_HOOK_LINK(gather_propsets)
>  APR_HOOK_LINK(find_liveprop)
>  APR_HOOK_LINK(insert_all_liveprops)
> +APR_HOOK_LINK(deliver_report)
> +APR_HOOK_LINK(gather_reports)
>  )
>
>  APR_IMPLEMENT_EXTERNAL_HOOK_VOID(dav, DAV, gather_propsets,
> @@ -5021,3 +5023,16 @@ APR_IMPLEMENT_EXTERNAL_HOOK_VOID(dav, DA
>   (request_rec *r, const dav_resource
> *resource,
>dav_prop_insert what, apr_text_header
> *phdr),
>   (r, resource, what, phdr))
> +
> +APR_IMPLEMENT_EXTERNAL_HOOK_RUN_FIRST(dav, DAV, int, deliver_report,
> +  (request_rec *r,
> +   const dav_resource *resource,
> +   const apr_xml_doc *doc,
> +   ap_filter_t *output, dav_error
> **err),
> +  (r, resource, doc, output, err),
> DECLINED)
> +
> +APR_IMPLEMENT_EXTERNAL_HOOK_VOID(dav, DAV, gather_reports,
> +   (request_rec *r, const dav_resource
> *resource,
> +apr_array_header_t *reports,
> dav_error **err),
> +   (r, resource, reports, err))
> +
>
> Modified: httpd/httpd/trunk/modules/dav/main/mod_dav.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/mod_dav.h?rev=1879306=1879305=1879306=diff
>
> ==
> --- httpd/httpd/trunk/modules/dav/main/mod_dav.h (original)
> +++ httpd/httpd/trunk/modules/dav/main/mod_dav.h Sun Jun 28 13:17:26 2020
> @@ -650,10 +650,10 @@ DAV_DECLARE(void) dav_xmlns_generate(dav
>  ** mod_dav 1.0). There are too many dependencies between a dav_resource
>  ** (defined by ) and the other functionality.
>  **
> -** Live properties are not part 

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

[Greg Stein]

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

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.

Cheers,
-g

Re: svn commit: r1872960 - /httpd/site/trunk/content/dev/release.mdtext

[Greg Stein]

$ svn info --show-item last-changed-revision $whatever

I think that's what you're looking for, in a simple command.

On Sat, Jan 18, 2020 at 9:00 AM  wrote:

> Author: druggeri
> Date: Sat Jan 18 15:00:05 2020
> New Revision: 1872960
>
> URL: http://svn.apache.org/viewvc?rev=1872960=rev
> Log:
> Add tag and revision to release vote email template
>
> Modified:
> httpd/site/trunk/content/dev/release.mdtext
>
> Modified: httpd/site/trunk/content/dev/release.mdtext
> URL:
> http://svn.apache.org/viewvc/httpd/site/trunk/content/dev/release.mdtext?rev=1872960=1872959=1872960=diff
>
> ==
> --- httpd/site/trunk/content/dev/release.mdtext (original)
> +++ httpd/site/trunk/content/dev/release.mdtext Sat Jan 18 15:00:05 2020
> @@ -230,6 +230,8 @@ The automated workflow is:
>
>  The computed digests of the tarball up for vote are:
>  `grep '^' httpd-$TAG.tar.gz.sha* | sed -e 's/.*.tar.gz.//g' -e 's/:/:
> /g'`
> +
> +The SVN tag is '$TAG' at r`svn info "
> https://svn.apache.org/repos/asf/httpd/httpd/tags/$TAG; | grep 'Revision'
> | awk '{print $2}'`.
>  "
>
>  # Wait for vote
>
>
>

Re: Migrate to git?

[Greg Stein]

On Tue, Oct 15, 2019 at 1:42 AM Ruediger Pluem  wrote:
>...

> Would we lose this possibility [of editing log messages] with git?
>

Yes.

The log message is part of the commit hash. You can effectively delete the
"tip" commit of a line-of-development, and replace it with a new commit
(ie. same code changes, but edited log msg). That new commit would have a
different hash. If people sync'd the old commit/hash, their clones are
basically broken post-edit.

It is effectively impossible to edit a log message if it is not-tip. That
is because each ongoing commit has a "parent [hash]" incorporated into its
hash signature. So if you go back in time to edit C1, then you're gonna to
regenerate hashes for C2, C3, and C4 that came after it. With the
corresponding breakage of clones.

Arguments can be made for whether this is pro/con, but I think is not worth
discussing here.

HTH,
-g

Re: Migrate to git?

[Greg Stein]

On Wed, Oct 9, 2019 at 7:59 AM Michal Karm  wrote:

> On 10/08/2019 10:44 AM, Greg Stein wrote:
> > On Tue, Oct 8, 2019 at 3:13 AM Joe Orton  > <mailto:jor...@redhat.com>> wrote:
> >
> > On Sat, Oct 05, 2019 at 04:09:34PM -0400, 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 :)
> >
> > Can we use Travis CI as well?  If so I am +1 on moving to github,
> being
> > able to easily configure a consistent CI across branches and PRs
> will be
> > a major improvement over the status quo.  (I have no idea how
> buildbot
> > works or how to improve it and it's unusuable before commits)
> >
> >
> > Travis CI is possible *today* ... since the svn commits are replicated
> over to
> > github, Travis can pick them up and run tests. Just file an INFRA ticket
> to
> > enable it.
> >
> > Cheers,
> > -g
> >
> Hi Greg,
>
> That does not cover Joe's note "...and PRs...".


I understand. Just noting that Travis is (already) possible, even if PR
handling/testing/merging is uneven.

Basically having a transparent,
> dead simple set of gate smoke tests
> on a handful of major platforms and config flavours/layouts. Linux and
> Windows
> can be used in this capacity for free (as in free beer).
>
> It makes almost no sense unless all committers agree that all code commits
> pass
> through PR gate, i.e.
> no direct commits.
>

Nope. Won't happen.

The httpd project has been "commit-then-review" for over two decades. "Must
past tests before merge" is antithetical, and I cannot possibly imagine
this community changing to that position.

>...

> Reading the email thread, I get the vibe that the community would have to
> put out the SVN vs. Git flame first though :)
>

FUD. That is not happening here at all. I'm one of the initial SVN
developers, but you won't see any flames from me, about git. I said "-0"
because I believe our community won't see the related growth that some
other projects see. It would be a change for little, if any, benefit. And I
already stated else-thread that I really like GitHub. ... it isn't about a
git/svn flame; it is about benefit/cost.

Cheers,
-g

Re: Migrate to git?

[Greg Stein]

On Tue, Oct 8, 2019 at 4:45 AM Nick Kew  wrote:
>...

> OK, that's not quite fair.  But isn't that what the github mirror is for?
>

Not even close to fair, stop that.

The github mirror is readonly. As noted upthread, that means merging PRs
and other activities are limited. It cannot act as a road to
expanding/growing our community (and again: -0 in any case).

Cheers,
-g

Re: Migrate to git?

[Greg Stein]

On Tue, Oct 8, 2019 at 3:13 AM Joe Orton  wrote:

> On Sat, Oct 05, 2019 at 04:09:34PM -0400, 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 :)
>
> Can we use Travis CI as well?  If so I am +1 on moving to github, being
> able to easily configure a consistent CI across branches and PRs will be
> a major improvement over the status quo.  (I have no idea how buildbot
> works or how to improve it and it's unusuable before commits)
>

Travis CI is possible *today* ... since the svn commits are replicated over
to github, Travis can pick them up and run tests. Just file an INFRA ticket
to enable it.

Cheers,
-g

Re: Migrate to git?

[Greg Stein]

On Sun, Oct 6, 2019, 11:52 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...
>

Not because of git, but due to GitHub. Git is "meh", but GitHub is a
fantastic tool.

>
> > Is this something the httpd project should consider?


-0 because I'm not sure it would improve contribution, though it would
certainly help some people with their workflow (think: mod_md)

>...

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

Those without GitHub IDs, or do not want to accept their T's would use
their Apache ID and commit to gitbox.a.o. Not a problem, already solved :-)

Cheers,
-g

Re: Changing mod_lua to stable

[Greg Stein]

On Fri, Jan 25, 2019 at 2:47 PM Chris Punches 
wrote:

> Someone may want to add some text along the lines of when to use u/WSGI
> instead of mod_lua as that's going to be a thing if this goes stable.  If
> the what/when isn't in there clearly we could run into really bad
> situations like ASF using mod_lua to host web services in production.
>

As D.Gruno noted, we *already* use mod_lua in production at the ASF, and
have seen zero problems with the module.

Cheers,
-g

Re: svn commit: r1841225 - /httpd/httpd/trunk/modules/dav/main/props.c

[Greg Stein]

On Mon, Nov 12, 2018 at 1:26 AM Ruediger Pluem  wrote:
>...

> The discussion died a little bit, because of the other issue (frequent
> writeev calls).
> I know that the liveprops issue is not fixed yet, but I guess it makes
> sense
> if you commit the patch you posted here already.
>

My time has been getting consumed by Infra. ... I hope to revisit one day,
but it looks like Joe is throwing in with some additional eyeballs.

Cheers,
-g

Re: Using APR pools "better"

[Greg Stein]

On Wed, Sep 26, 2018 at 10:20 AM Daniel Shahaf 
wrote:

> Jim Jagielski wrote on Wed, 26 Sep 2018 11:09 -0400:
> > At ApacheCon's welcoming event last night, Greg, Sander and I were
> > chatting and Greg reminded us that the Subversion project "learned a lot
> > about using APR pools" and it seems to me that a lot of that knowledge
> > is likely missing in httpd-land. I also know that some of that has been
> > backported back to APR itself, but I am wondering (as I am wont to do),
> > if we couldn't do a better job here. I am sure that there are things in
> > svn that could be easily and readily folded back into APR w/o breaking
> > anything.
> >
> > I know that some of that influenced Greg's PoCore work, but it would be
> > really cool if someone in Subversion could maybe point out some of those
> > improvements and "lessons learned" so that both APR and httpd could
> > benefit.
>
> For starters, here's what we've already written down:
>
>
> https://subversion.apache.org/docs/community-guide/conventions.html#apr-pools
>
> I would especially point out the result_pool/scratch_pool distinction:
> each function gets *two* pools, one in which to allocate the return
> value, and one whose lifetime is defined as "the pool may be deleted at
> any time after the function returns".
>
> For example, when one calls a function declared as:
> .
> apr_status_t find_foo(foo_t *outparam, ..., apr_pool_t *result_pool,
> apr_pool_t *scratch_pool)
> .
> then on return *outparam will be allocated in result_pool, and
> apr_pool_clear(scratch_pool) may be called as soon as find_foo()
> returned.


Yup.


>   Thus, scratch_pool is passed into the result_pool formal
> parameter of functions find_foo() calls, is the pool iterpools are created
> as subpools of, etc. .
>

This is a bit unclear, so skip this and go read the page :-)


> I'm sure Greg is subscribed to at least one of these lists and will add
> anything I forgot :)


All three, actually :-) ... and the pointer to the coding convention page
is exactly what I wanted to point the other groups at.

iterpool, scratch_pool, and result_pool are the KEY three concepts that we
learned while working on Subversion. Also relying on your *caller* to know
more about memory management / lifetimes. The conventions page does a
really great job of describing what we learned, and we're here to
expand/answer where it isn't (and #fixthedoc :-P ), and/or provide further
examples to clarify.

Cheers,
-g

Re: svn commit: r1841225 - /httpd/httpd/trunk/modules/dav/main/props.c

[Greg Stein]

We learned a lot about pool handling while writing Subversion, after I
wrote that mod_dav code. There are definite some improvements to be made.
I'm not surprised that a propfind can go nuts like that ... I'll review the
change and take a look generally.

h/t to DanielR for the pointer to this thread.


On Tue, Sep 18, 2018 at 8:04 AM Ruediger Pluem  wrote:

> Pools are very tricky in mod_dav. Hence additional eyeballs are very much
> welcome here.
> As I only did testing with mod_dav_fs I would be keen to know if things
> still work with Subversion.
> So if someone from the Subversion guys is listening here: Having this
> tested with Subversion would be very welcome :-).
>
> Regards
>
> Rüdiger
>
> On 09/18/2018 02:58 PM, rpl...@apache.org wrote:
> > Author: rpluem
> > Date: Tue Sep 18 12:58:57 2018
> > New Revision: 1841225
> >
> > URL: http://svn.apache.org/viewvc?rev=1841225=rev
> > Log:
> > * Doing a PROPFIND on a large collection e.g. 50.000 elements can easily
> >   consume 1 GB of memory as the subrequests and propdb pools are not
> >   destroyed and cleared after each element was handled.
> >   Do this now. There is one case in dav_get_props where elem->priv
> >   lives longer then the propdb pool. In this case allocate from r->pool.
> >   Furthermore also recycle propdb's which allows to clear the propdb's
> >   pools instead of destroying them and creating them again.
> >
> > Modified:
> > httpd/httpd/trunk/modules/dav/main/props.c
> >
> > Modified: httpd/httpd/trunk/modules/dav/main/props.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/props.c?rev=1841225=1841224=1841225=diff
> >
> ==
> > --- httpd/httpd/trunk/modules/dav/main/props.c (original)
> > +++ httpd/httpd/trunk/modules/dav/main/props.c Tue Sep 18 12:58:57 2018
> > @@ -524,7 +524,21 @@ DAV_DECLARE(dav_error *)dav_open_propdb(
> >  apr_array_header_t * ns_xlate,
> >  dav_propdb **p_propdb)
> >  {
> > -dav_propdb *propdb = apr_pcalloc(r->pool, sizeof(*propdb));
> > +dav_propdb *propdb = NULL;
> > +/*
> > + * Check if we have tucked away a previous propdb and reuse it.
> > + * Otherwise create a new one and tuck it away
> > + */
> > +apr_pool_userdata_get((void **), "propdb", r->pool);
> > +if (!propdb) {
> > +propdb = apr_pcalloc(r->pool, sizeof(*propdb));
> > +apr_pool_userdata_setn(propdb, "propdb", NULL, r->pool);
> > +apr_pool_create(>p, r->pool);
> > +}
> > +else {
> > +/* Play safe and clear the pool of the reused probdb */
> > +apr_pool_clear(propdb->p);
> > +}
> >
> >  *p_propdb = NULL;
> >
> > @@ -537,7 +551,6 @@ DAV_DECLARE(dav_error *)dav_open_propdb(
> >  #endif
> >
> >  propdb->r = r;
> > -apr_pool_create(>p, r->pool);
> >  propdb->resource = resource;
> >  propdb->ns_xlate = ns_xlate;
> >
> > @@ -562,10 +575,12 @@ DAV_DECLARE(void) dav_close_propdb(dav_p
> >  (*propdb->db_hooks->close)(propdb->db);
> >  }
> >
> > -/* Currently, mod_dav's pool usage doesn't allow clearing this
> pool. */
> > -#if 0
> > -apr_pool_destroy(propdb->p);
> > -#endif
> > +if (propdb->subreq) {
> > +ap_destroy_sub_req(propdb->subreq);
> > +propdb->subreq = NULL;
> > +}
> > +
> > +apr_pool_clear(propdb->p);
> >  }
> >
> >  DAV_DECLARE(dav_get_props_result) dav_get_allprops(dav_propdb *propdb,
> > @@ -815,7 +830,8 @@ DAV_DECLARE(dav_get_props_result) dav_ge
> >  */
> >
> >  if (elem->priv == NULL) {
> > -elem->priv = apr_pcalloc(propdb->p, sizeof(*priv));
> > +/* elem->priv outlives propdb->p. Hence use the request
> pool */
> > +elem->priv = apr_pcalloc(propdb->r->pool, sizeof(*priv));
> >  }
> >  priv = elem->priv;
> >
> >
> >
> >
>

Re: Start using RCs (Was: Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)])

[Greg Stein]

On Sun, Apr 22, 2018 at 11:34 AM, Daniel Ruggeri 
wrote:

> Yeah - I think my main concern is really just around the backporting
> process with STATUS and how that will have issues scaling across many
> branches. Further, as each branch deviates, it becomes more of a
> cognitive exercise for developers to figure out if the fix in branch XYZ
> is applicable and the same in ABC.
>
> The more I think about it, the more I *really* like a semver-ish
> approach where major represents the ABI that will not be broken, minor
> represents the feature set (for backwards compatibility) and patch
> represents forward-compatible changes/fixes.


Apache Subversion takes the patch number much more literally. They are
merely fixes to behavior defined in the minor release. The API/ABI is never
touched during a patch release. You could build against 1.7.13, then
install 1.7.0 and your code works against it. Then upgrade svn to 1.7.20
and it still works. Downgrade to 1.7.5 ... you get the picture.

I see several issues with the recent threads of discussion:

* How releases are numbered, and what guarantees are made relative to those
numbers
* What kinds of gating of features/fixes is defined by the process?
* How are branches created/maintained, relative to the above

Classic httpd numbering can certainly be made to work (empirically: it
has). semver is well-documented, understood, and downstream users would not
need to understand our quirks. It does kind of impose decisions on gating
of features, though (Q2 above).

It is unclear what problem is being solved. It seems like the unpredictable
feature set of 2.4.x. And/or when to stop loading features into that, and
start a 2.6.x series. (or 3.0?)

Cheers,
-g

ps. my vote is for semver and strict controls on patch releases. chew
through release numbers. they are cheap. downstream will pick one release
and run with that. it doesn't matter to them if we have a new minor every
six months (which means new features, which distros won't pick those
features from patch releases anyways; may as well move them to a minor)

Re: Versioning, Release Management, Stabilization, etc ... Subversion style

[Greg Stein]

A useful, well-documented process of a fellow Apache community ... a
process that has worked steadily and produced (your words) "outstanding
stability, backwards compat, and steadily add new features, big and small".

We're talking process, not the merits of software package that uses it (and
this isn't the place to argue svn's merits).

Frankly, HTTPD does not have a well-documented process to balance
stability, compatibility, and progress. Leveraging svn's process could be
helpful, with some tuning specific to the httpd community.

Cheers,
-g


On Fri, Apr 20, 2018 at 4:18 PM, Martin Langhoff <martin.langh...@gmail.com>
wrote:

> (as a completely external voice, user, packager, architect of systems big
> and small) - would it not make sense to model the workflow of a project
> that has a more positive feature _and_ stability profile?
>
> With all due respect, Subversion is an old project, offering little new,
> with a dwindling userbase. New adoptions of subversion are not something
> you hear about.
>
> I would instead look at git -- not because it's an SCM, but because it's a
> smaller, simpler, and less "personality-driven" version of the Linux kernel
> workflow. Or PostgreSQL, which is evolving towards something similar but
> even less personality-driven.
>
> Both git and Pg offer really outstanding stability, backwards compat, and
> steadily add new features, big and small. Every time I look I am pleasantly
> surprised of the new bits added.
>
> with high regards, and respect,
>
>
>
> martin
>
> On Fri, Apr 20, 2018 at 10:05 AM, Jim Jagielski <j...@jagunet.com> wrote:
>
>> Great info! Thanks!
>>
>>
>> On Apr 20, 2018, at 9:52 AM, Greg Stein <gst...@gmail.com> wrote:
>>
>> Hi all,
>>
>> I've been kind of watching the thrashing around on several threads now
>> about problems and fixes to how the HTTPD project manages its process
>> around releases. I thought it might be a good idea to suggest a
>> tried-and-true alternative defined by the Apache Subversion project, and
>> documented extensively at [1].
>>
>> That is a lot to wade through, and parts just don't apply ... but even
>> reading some of that could be helpful when read as a comparative point to
>> how HTTPD historically does its T and branch/release management. That
>> Subversion "manual" on releases is very stable, and what we've been
>> doing/developed during our 18 years, especially with the project's
>> understanding of version control, and svn specifically :-)
>>
>> Read the "Stabilizing and maintaining releases" section at a minimum,
>> please. That is kind of core to some of the issues on the mailing list
>> recently, and it describes how Subversion does things.
>>
>> I don't want to write a tome, but to begin a discussion to adopt that
>> documented approach with tweaks for httpd. So to write a shorter note, I'd
>> basically summarize as:
>>
>> * all development occurs on trunk
>> * release branches are made off trunk for each MINOR release (see the
>> 1.$N.x branches at [2])
>> * stabilization occurs on release branches by only cherry-picking
>> existing work/changes off of trunk
>> * when a release branch is made, trunk's version is bumped (ie. say trunk
>> is 2.5, the 2.6.x branch is made, then trunk becomes 2.7)
>> * IMO, don't bother making 2.7.x releases; just use the number to
>> determine if somebody grabbed a snapshot of trunk (svn happens to be
>> 1.11.0-dev in trunk, and will become 1.12.0-dev once the 1.11.x branch is
>> made; the svn project looks for a reported version of "-dev" for such
>> snapshot behavior) ... if you're going to think about a 2.7.x "test"
>> release, then just make it 2.8.x instead and label the feature experimental.
>> * trunk is always stable and passes buildbot tests
>> * version numbers are cheap, feel free to burn them (see our CHANGES[3]
>> where many specific numbers are recorded as "Not released")
>> * Subversion has its own compatibility declarations defined around
>> major/minor; I'd suggest skip that and stick to the existing HTTPD "MMN"
>> system
>>
>> I think that is most of the highlights. Again: I'd suggest reading the
>> section on Stabilization, and maybe "Creating and maintaining release
>> branches" section. The whole page for extra credit :-)
>>
>> Cheers,
>> -g
>>
>> [1] http://subversion.apache.org/docs/community-guide/releasing.html
>> [2] http://svn.apache.org/repos/asf/subversion/branches/
>> [3] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES
>>
>>
>>
>
>
> --
>  martin.langh...@gmail.com
>  - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
>  - don't be distracted~  http://github.com/martin-langhoff
>by shiny stuff
>

Versioning, Release Management, Stabilization, etc ... Subversion style

[Greg Stein]

Hi all,

I've been kind of watching the thrashing around on several threads now
about problems and fixes to how the HTTPD project manages its process
around releases. I thought it might be a good idea to suggest a
tried-and-true alternative defined by the Apache Subversion project, and
documented extensively at [1].

That is a lot to wade through, and parts just don't apply ... but even
reading some of that could be helpful when read as a comparative point to
how HTTPD historically does its T and branch/release management. That
Subversion "manual" on releases is very stable, and what we've been
doing/developed during our 18 years, especially with the project's
understanding of version control, and svn specifically :-)

Read the "Stabilizing and maintaining releases" section at a minimum,
please. That is kind of core to some of the issues on the mailing list
recently, and it describes how Subversion does things.

I don't want to write a tome, but to begin a discussion to adopt that
documented approach with tweaks for httpd. So to write a shorter note, I'd
basically summarize as:

* all development occurs on trunk
* release branches are made off trunk for each MINOR release (see the
1.$N.x branches at [2])
* stabilization occurs on release branches by only cherry-picking existing
work/changes off of trunk
* when a release branch is made, trunk's version is bumped (ie. say trunk
is 2.5, the 2.6.x branch is made, then trunk becomes 2.7)
* IMO, don't bother making 2.7.x releases; just use the number to determine
if somebody grabbed a snapshot of trunk (svn happens to be 1.11.0-dev in
trunk, and will become 1.12.0-dev once the 1.11.x branch is made; the svn
project looks for a reported version of "-dev" for such snapshot behavior)
... if you're going to think about a 2.7.x "test" release, then just make
it 2.8.x instead and label the feature experimental.
* trunk is always stable and passes buildbot tests
* version numbers are cheap, feel free to burn them (see our CHANGES[3]
where many specific numbers are recorded as "Not released")
* Subversion has its own compatibility declarations defined around
major/minor; I'd suggest skip that and stick to the existing HTTPD "MMN"
system

I think that is most of the highlights. Again: I'd suggest reading the
section on Stabilization, and maybe "Creating and maintaining release
branches" section. The whole page for extra credit :-)

Cheers,
-g

[1] http://subversion.apache.org/docs/community-guide/releasing.html
[2] http://svn.apache.org/repos/asf/subversion/branches/
[3] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES

Re: "Most Popular Web Server?"

[Greg Stein]

Just. Stop.

On Wed, Apr 18, 2018 at 5:29 PM, Jim Jagielski  wrote:

>
>
> > On Apr 18, 2018, at 2:32 PM, William A Rowe Jr 
> wrote:
> >
> > On Wed, Apr 18, 2018 at 1:07 PM, Jim Jagielski  wrote:
> >>
> >>> On Apr 18, 2018, at 1:21 PM, William A Rowe Jr 
> wrote:
> >>>
> >>> There we go again. Why do you and Graham have to make this about
> >>> Bill vs. yourselves?
> >>
> >> I didn't.
> >
> > It's a challenge to read this otherwise;
> >
>
> I used the term "we" consistently. If, for some reason, you see
> things in what I say that you think may align w/ behaviors that
> you attribute to yourself, that is you putting that on, not me.
>
>

Re: TLSv1.3

[Greg Stein]

On Thu, Mar 29, 2018 at 3:16 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:
>...

> That is the intention behind "SSLPolicy modern|intermediate|old" that
> configures the TLS stack according to the Mozilla server-side-tls
> recommendations. So, one does not have to mess with many directives to have
> a site with an "A" SSL Labs rating.
>
> Besides, except for data center setups, Apache will be used *only* with
> https: (and http: redirects to https:) very, very soon. That shifts the
> average expertise of an admin setting up a https: site.
>
> Back to TLSv1.3:
>
> I do not like to invent new config directives for a new TLS version
> either. The protocol on/off switch is now in "SSLProtocol" and that's where
> it should be. AFAIK, it's only the cipher list that needs special treatment
> (if one wants to override defaults or what SSLPolicy will do for it, once a
> recommendation is out).
>

Gotcha.


>
> So, looking at "SSLCipherSuite". It basically passes the string to the
> *SSL library. The manual page makes a big explanation and tables of
> ciphers, but the lists repeats basically how OpenSSL cipher strings work.
> It would be better to scrap that and replace it with a link to
> https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl
> has nicer documentation)
>
> Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to
> take more than 1 argument and look for optional prefixes to the suite
> strings given, so one could do
>

Oooh! Yes. Looks great.

+1

>...

Cheers,
-g

Re: TLSv1.3

[Greg Stein]

On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:

> Just added TLSv1.3 support in trunk. No fancy new early data features,
> just the basic.
>
> Open for discussion:
>  - The Mozilla server-side-tls people are still thinking of what they will
> recommend, see:
>https://github.com/mozilla/server-side-tls/issues/191#
> issuecomment-376918933
>  - Turns out, cipher suites are separate from <= TLSv1.2. Since servers
> will co-host 1.2 and 1.3
>for some time, we need additional config directives, I think. Added
> "SSLCipherSuiteV1_3" and
>am ashamed of the name.
>

Why not something simple like:

TLSVersion 1.3

and have that impute a specific set of ciphers? Get's away from the old
"SSL" name, and moves us to a directive that can accept version into the
future (instead of a new directive every time).

And if you want to *refine* the behavior, then do it with new TLS*
directives. I've always had a problem with setting up TLS servers because
of the huge number of directives. It would be nice to just introduce a new,
simple directive that produces "all" the default handling for the majority
of users.


>  - The current handling of TLS versions that are not supported by the *SSL
> lib linked is not
>super helpful. It more or less pretends that the version does not exist
> (unknown protocol),
>but that is far from the truth. Shall we continue that or is this an
> opportunity to reconsider?
>

Euh, if the underlying libraries cannot support a new TLS version, *and*
httpd hasn't been coded to support that version, then yes: it should fail.
Both parts are needed.

Did I misunderstand your query?


>  - Should we allow the configuration of TLSv1_3 ciphers, even if the
> linked SSL does not support
>it? This is different from SSLProtocol which of course needs to fail if
> it cannot enable the
>version that is explicitly configured.
>I think it is ok to take it into the config, even though it never
> activates.
>

Oh no no. If I want to configure "SuperAwesomeGJSCipher", and that isn't
available like I *expect* it to be ... then yeah. "Cipher not available.
You won't get the security you're seeking." #FAIL

Cheers,
-g

Re: svn commit: r1822849 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Greg Stein]

Any comment is a good comment :-)

(I don't understand the logic in there, so can't really comment on the
substance ... just noted the removal of all commentary)

Thanks!
-g


On Thu, Feb 1, 2018 at 2:36 AM, Plüm, Rüdiger, Vodafone Group <
ruediger.pl...@vodafone.com> wrote:

> Thanks for the review. Does r1822858 address your concern?
>
>
>
> Regards
>
>
>
> Rüdiger
>
>
>
> *Von:* Greg Stein [mailto:gst...@gmail.com]
> *Gesendet:* Donnerstag, 1. Februar 2018 09:01
> *An:* dev@httpd.apache.org
> *Betreff:* Re: svn commit: r1822849 - /httpd/httpd/trunk/modules/
> proxy/proxy_util.c
>
>
>
>
>
>
>
> On Thu, Feb 1, 2018 at 1:34 AM, <rpl...@apache.org> wrote:
>
> Author: rpluem
> Date: Thu Feb  1 07:34:02 2018
> New Revision: 1822849
>
> URL: http://svn.apache.org/viewvc?rev=1822849=rev
> Log:
> * When mod_http2 is loaded more then ThreadsPerChild backend connections
> can
>   be useful as mod_http2 has an additional thread pool on top of
>   ThreadsPerChild.
>   But leave the default with ThreadsPerChild.
>
> Modified:
> httpd/httpd/trunk/modules/proxy/proxy_util.c
>
> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/
> proxy/proxy_util.c?rev=1822849=1822848=1822849=diff
> 
> ==
> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Thu Feb  1 07:34:02 2018
> @@ -1841,8 +1841,7 @@ PROXY_DECLARE(apr_status_t) ap_proxy_ini
>
>  ap_mpm_query(AP_MPMQ_MAX_THREADS, _threads);
>  if (mpm_threads > 1) {
> -/* Set hard max to no more then mpm_threads */
> -if (worker->s->hmax == 0 || worker->s->hmax > mpm_threads) {
> +if (worker->s->hmax == 0) {
>  worker->s->hmax = mpm_threads;
>
>
>
> Would be nice to leave *some* kind of explanatory comment in there.
> Without that comment, the only explanation is "way over there" in commit
> log messages.
>
>
>
> Cheers,
>
> -g
>
>
>

Re: svn commit: r1822849 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Greg Stein]

On Thu, Feb 1, 2018 at 1:34 AM,  wrote:

> Author: rpluem
> Date: Thu Feb  1 07:34:02 2018
> New Revision: 1822849
>
> URL: http://svn.apache.org/viewvc?rev=1822849=rev
> Log:
> * When mod_http2 is loaded more then ThreadsPerChild backend connections
> can
>   be useful as mod_http2 has an additional thread pool on top of
>   ThreadsPerChild.
>   But leave the default with ThreadsPerChild.
>
> Modified:
> httpd/httpd/trunk/modules/proxy/proxy_util.c
>
> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/
> proxy/proxy_util.c?rev=1822849=1822848=1822849=diff
> 
> ==
> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Thu Feb  1 07:34:02 2018
> @@ -1841,8 +1841,7 @@ PROXY_DECLARE(apr_status_t) ap_proxy_ini
>
>  ap_mpm_query(AP_MPMQ_MAX_THREADS, _threads);
>  if (mpm_threads > 1) {
> -/* Set hard max to no more then mpm_threads */
> -if (worker->s->hmax == 0 || worker->s->hmax > mpm_threads) {
> +if (worker->s->hmax == 0) {
>  worker->s->hmax = mpm_threads;
>

Would be nice to leave *some* kind of explanatory comment in there. Without
that comment, the only explanation is "way over there" in commit log
messages.

Cheers,
-g

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

[Greg Stein]

To be clear: "delete" simply means "no longer seen in HEAD". This is
version control. The data cannot truly be deleted, so it can always be
revived. Or reviewed.

On Oct 25, 2017 12:31, "Marion & Christophe JAILLET" <
christophe.jail...@wanadoo.fr> wrote:

> Just to mention that before giving a +1, I made a copy of these
> repositories in order to dig later on, in order to see if something useful
> seems to be there.
> Don't have that much time these days to play with httpd, but will do and
> will report anything that looks valuable.
>
> CJ
>
>
> Le 25/10/2017 à 14:29, Jim Jagielski a écrit :
>
>> Are there anything of "value" in any of those branches?
>>
>> If not, prune away!
>>
>> On Oct 24, 2017, at 9:11 AM, William A Rowe Jr 
>>> wrote:
>>>
>>> On Tue, Oct 24, 2017 at 3:28 AM, Steffen  wrote:
>>>
 On Tuesday 24/10/2017 at 10:26, Steffen wrote:

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

 httpd 2.4.1 was tagged at r1243503.
>>>
>>> I'd propose we start by pruning all working branches not updated since
>>> this tag.
>>>
>>> Thoughts?
>>>
>>
>>
>

Re: svn commit: r1804671 - /httpd/httpd/trunk/modules/md/mod_md_config.c

[Greg Stein]

Oh, I don't know that Infra has any specific request on the restart/update
mechanism. I'd just say: build it how you think best. What would work for
Everybody should work just fine for us.

On Mon, Aug 14, 2017 at 2:09 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:

> Thanks for the feedback and the crosspost. I think it would be great to
> offer peeps
> that already link serf into their server to avoid an additional dependency.
>
> Regarding Apache infrastructure use:
>
> Would you prefer that the server gracefully restarts itself (when needed,
> at a time
> interval configured?) or is this something where you prefer outside
> control anyway and
> maybe a callable script that notifies/mails an admin?
>
> -Stefan
>
> > Am 14.08.2017 um 07:43 schrieb Greg Stein <gst...@gmail.com>:
> >
> > [cc: serf]
> >
> > On Fri, Aug 11, 2017 at 3:41 AM, Stefan Eissing <
> stefan.eiss...@greenbytes.de> wrote:
> > >...
> > If you're looking at this anyway, how hard would it be for someone
> knowledgeable to make a md_serf.c as alternative to md_curl.c? ^^
> >
> > Should be pretty easy, I think. Looking at serf_get.c will give somebody
> an easy path to build the alternative:
> >   http://svn.apache.org/repos/asf/serf/trunk/test/serf_get.c
> >
> > There is a lot of stuff in there that isn't applicable, so the core
> should be quite small/easy. And it uses APR pools (and whatnot), so the
> impedance should be very low.
> >
> > While I'm busy over in Infra-land, there are other Serf people here and
> happy to help. I'll certainly throw in on some reviews, if/when I see the
> commits.
> >
> > And from ASF/Infra side: we'd love to see this code hit a release soon.
> We've been very hesitant to use LE in our deployments because the httpd and
> puppet config/scripts are quite rough. It doesn't "Just Work". This would
> go a long ways towards solving numerous certificate-related issues for us.
> >
> > Thanks,
> > -g
> >
>
>

Re: svn commit: r1804671 - /httpd/httpd/trunk/modules/md/mod_md_config.c

[Greg Stein]

[cc: serf]

On Fri, Aug 11, 2017 at 3:41 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:
>...

> If you're looking at this anyway, how hard would it be for someone
> knowledgeable to make a md_serf.c as alternative to md_curl.c? ^^
>

Should be pretty easy, I think. Looking at serf_get.c will give somebody an
easy path to build the alternative:
  http://svn.apache.org/repos/asf/serf/trunk/test/serf_get.c

There is a lot of stuff in there that isn't applicable, so the core should
be quite small/easy. And it uses APR pools (and whatnot), so the impedance
should be very low.

While I'm busy over in Infra-land, there are other Serf people here and
happy to help. I'll certainly throw in on some reviews, if/when I see the
commits.

And from ASF/Infra side: we'd love to see this code hit a release soon.
We've been very hesitant to use LE in our deployments because the httpd and
puppet config/scripts are quite rough. It doesn't "Just Work". This would
go a long ways towards solving numerous certificate-related issues for us.

Thanks,
-g

Re: svn commit: r1804671 - /httpd/httpd/trunk/modules/md/mod_md_config.c

[Greg Stein]

On Thu, Aug 10, 2017 at 8:58 AM,  wrote:

> Author: icing
> Date: Thu Aug 10 13:58:26 2017
> New Revision: 1804671
>
> URL: http://svn.apache.org/viewvc?rev=1804671=rev
> Log:
> fix for 
>...

> +++ httpd/httpd/trunk/modules/md/mod_md_config.c Thu Aug 10 13:58:26 2017
>
>...

> @@ -215,7 +218,7 @@ static const char *md_config_sec_add_mem
>  const char *err;
>  int i;
>
> -if (NULL != (err = md_section_check(cmd))) {
> +if (NULL != (err = md_section_check(cmd, "

Seems you should be using a symbolic constant for the dozen occurrences of
this string, in order to avoid typos.

>...

Cheers,
-g

Re: svn commit: r1803072 - /httpd/site/trunk/content/security/vulnerabilities-httpd.page/securitydb.xsl

[Greg Stein]

Hey Bill,

There was a misconfigured LDAP server ... that was fixed earlier today, so
you should be good to go now!

Cheers,
-g


On Wed, Jul 26, 2017 at 2:53 PM, William A Rowe Jr  wrote:

> I would push this edit live (looking good from a local regen here), but
> https://cms.a.o has been down for a number of hours. bcc'ing root@
> so that they are aware that we've lost that control panel, @infrabot
> hasn't posted a status on the service.
>
> Cheers,
>
> Bill
>
> > Author: wrowe
> > Date: Wed Jul 26 16:30:47 2017
> > New Revision: 1803072
> >
> > URL: http://svn.apache.org/viewvc?rev=1803072=rev
> > Log:
> > Generate A-name tag for CVE entries, follow sp-slash-gt pattern for
> output html
> >
> > Modified:
> > httpd/site/trunk/content/security/vulnerabilities-
> httpd.page/securitydb.xsl
>

Re: httpd and letsencrypt

[Greg Stein]

Anything new on this?

On Sep 15, 2016 00:35, "Dale Ghent"  wrote:

>
> Apologies from necro’ing this thread, I’m just catching up.
>
> As a maintainer/user of a lesser-known open source OS (OmniOS, based on
> illumos, which is the carry-on of what you all might remember as
> OpenSolaris after Oracle killed it) I’ve had my own issues around
> attempting to select a suitable letsencrypt client that works on OmniOS and
> maintaining it. I’ve got one working (getssl) and it’s basically a giant
> shell script with modifications to work in our native userland.
>
> The plain matter for people like myself is that most letsencrypt clients
> out there are either Python or Shell script, with the former tending to
> require non-mainstream C modules that don’t play well on anything outside
> of Linux or *BSD, and the latter written with GNU userlands in mind. The
> prospect of having cert management baked in to Apache httpd is tantalizing
> - a perhaps more platform-agnostic approach that replaces the mess of
> scripts and cronjobs that we see today.
>
> Of course it would be an optional module, and anyone turning it on with a
> pre-existing LE setup should do so in an orderly way. Either way,
> facilitating SSL certs in light of HTTP/2 would be something I would be
> happy to see, even if at any other time such a facility would be seen as
> outside the scope of httpd.
>
> /dale
>
> > On Aug 26, 2016, at 5:08 PM, William A Rowe Jr 
> wrote:
> >
> > I think this is great, in concept.
> >
> > My experience with letsencrypt (which was quite good, FWIW) is that
> > the project delivered a contained and trusted environment to sync and
> > deliver new keys and retrieve signed certificates. I'll be interested to
> see
> > what simplification is presented, I don't think we want to get into the
> > business of delivering container-style distributions of httpd.
> >
> >
> >
> > On Fri, Aug 26, 2016 at 9:47 AM, Rich Bowen  wrote:
> > At LinuxCon I spoke with the director of the LetsEncrypt project - whose
> > business card I haven't yet found in unpacking - and he asked whether
> > the httpd project would be interested in LetsEncrypt being "in" httpd.
> > That is, when one installs httpd, letsencrypt would just be a config
> > option. (I have no idea how this would actually work, but that's beside
> > the point really.)
> >
> > Is this something that we'd be interested in, if it were contributed? I
> > note that their software is under the Apache License, so there shouldn't
> > be any difficulty on that front.
> >
> > Naturally, I told him that the next step was to get on this mailing list
> > and talk about implementation details, and he said he'd do that. So that
> > should be coming in the next week, as soon as I find his business card
> > and send him the subscribe info and so on.
> >
> > --
> > Rich Bowen - rbo...@rcbowen.com - @rbowen
> > http://apachecon.com/ - @apachecon
> >
>
>

Re: mod_h2 CTR (Was: Re: svn commit: r1705257 - /httpd/httpd/trunk/modules/http2/config.m4)

[Greg Stein]

On Fri, Sep 25, 2015 at 11:51 AM, Rainer Jung 
wrote:

> Am 25.09.2015 um 17:56 schrieb Plüm, Rüdiger, Vodafone Group:
>
>> ...
>>> +1 on CTR for mod_h2 in 2.4.x
>>>
>>>
>> Just to clarify: CTR only on the code in modules/http2. All changes /
>> adjustments that might be needed to mod_ssl should stay RTC.
>>
>
> +1 as detailed by Rüdiger.
>

+1

IMO, call it experimental, and detail what that means in the release notes
or an FAQ on the site.

Cheers,
-g

Re: svn move modules/http2 modules/h2 ?

[Greg Stein]

Yeah... if anything, rename to mod_http2.

On Tue, Sep 22, 2015 at 12:01 PM, Gregg Smith  wrote:

> http2 is more descriptive for the module's purpose, even if the name is
> mod_h2. I like it where it is.
> - 0
>
>
> On 9/22/2015 5:08 AM, Stefan Eissing wrote:
>
>> +0.5
>>
>> h2 ftw! (but there is also a mod_mime in the http dir, so I do not really
>> feel strongly about this)
>>
>> Am 22.09.2015 um 14:05 schrieb Yann Ylavic:
>>>
>>> I'm confused about the sources being in modules/http2 and the module
>>> being mod_h2 (configured with --enable-h2, ...), it seems to be the
>>> only one like this.
>>>
>>> +1 for me...
>>>
>> bytes GmbH
>> Hafenweg 16, 48155 Münster, Germany
>> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>>
>>
>>
>>
>

Re: svn commit: r1703415 - in /httpd/test/framework/trunk/c-modules: authany/mod_authany.c test_session/mod_test_session.c

[Greg Stein]

On Wed, Sep 16, 2015 at 9:18 AM,  wrote:

> Author: jim
> Date: Wed Sep 16 14:18:49 2015
> New Revision: 1703415
>
>...

> Modified:
> httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> URL:
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c?rev=1703415=1703414=1703415=diff
>
> ==
> --- httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> (original)
> +++ httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> Wed Sep 16 14:18:49 2015
> @@ -149,7 +149,6 @@ static apr_status_t test_session_encode(
>
>  static apr_status_t test_session_decode(request_rec * r, session_rec * z)
>  {
> -apr_status_t result = OK;
>  const size_t prefix_len = strlen(TEST_SESSION_ENCODING_PREFIX);
>  test_session_dcfg_t *dconf = ap_get_module_config(r->per_dir_config,
>
>  _session_module);
> @@ -203,7 +202,7 @@ static int test_session_handler(request_
>  return DECLINED;
>
>  /* Copy the header for SessionHeader from the request to the
> response. */
> -if (overrides = apr_table_get(r->headers_in, TEST_SESSION_HEADER))
> +if ((overrides = apr_table_get(r->headers_in, TEST_SESSION_HEADER)))
>  apr_table_setn(r->headers_out, TEST_SESSION_HEADER, overrides);
>
>  /* Additional commands to test the session API via POST. */
> @@ -240,15 +239,15 @@ static int test_session_handler(request_
>  }
>  else if (!strcmp(pair->name, "name")) {
>  apr_size_t len;
> -apr_brigade_length(pair->value, 1, );
> +apr_brigade_length(pair->value, 1, (apr_off_t *));
>

This seems really dangerous. Aren't there cases where sizeof(apr_size_t) !=
sizeof(apr_off_t) ??


>  fieldName = apr_pcalloc(r->pool, sizeof(char) * len + 1);
> -result = apr_brigade_flatten(pair->value, fieldName,
> );
> +result = apr_brigade_flatten(pair->value, fieldName,
> (apr_size_t *));
>

This seems unnecessary.  should already be apr_size_t *


>  }
>  else if (!strcmp(pair->name, "value")) {
>  apr_size_t len;
> -apr_brigade_length(pair->value, 1, );
> +apr_brigade_length(pair->value, 1, (apr_off_t *));
>  fieldValue = apr_pcalloc(r->pool, sizeof(char) * len + 1);
> -result = apr_brigade_flatten(pair->value, fieldValue,
> );
> +result = apr_brigade_flatten(pair->value, fieldValue,
> (apr_size_t *));
>

These two, same as above.

Heh. I haven't reviewed httpd code for years. But I saw a change to
mod_authany.c and thought "what is that? isn't that module crazy stable?"
... curiosity :-P

Cheers,
-g

Re: svn commit: r1703415 - in /httpd/test/framework/trunk/c-modules: authany/mod_authany.c test_session/mod_test_session.c

[Greg Stein]

Yeah... I do like -Werror, so that forces a clean build, so that *real*
warnings don't get buried in a bunch of useless warnings.

On Wed, Sep 16, 2015 at 10:08 AM, Jim Jagielski <j...@jagunet.com> wrote:

> All this is due to changes mode with the mainter-mode and
> which causes build stop error and stop for these kinds
> of warnings. These are simple 'squash warning' patches.
>
> > On Sep 16, 2015, at 10:50 AM, Greg Stein <gst...@gmail.com> wrote:
> >
> > On Wed, Sep 16, 2015 at 9:18 AM, <j...@apache.org> wrote:
> > Author: jim
> > Date: Wed Sep 16 14:18:49 2015
> > New Revision: 1703415
> > >...
> > Modified:
> httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> > URL:
> http://svn.apache.org/viewvc/httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c?rev=1703415=1703414=1703415=diff
> >
> ==
> > --- httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> (original)
> > +++ httpd/test/framework/trunk/c-modules/test_session/mod_test_session.c
> Wed Sep 16 14:18:49 2015
> > @@ -149,7 +149,6 @@ static apr_status_t test_session_encode(
> >
> >  static apr_status_t test_session_decode(request_rec * r, session_rec *
> z)
> >  {
> > -apr_status_t result = OK;
> >  const size_t prefix_len = strlen(TEST_SESSION_ENCODING_PREFIX);
> >  test_session_dcfg_t *dconf = ap_get_module_config(r->per_dir_config,
> >
> _session_module);
> > @@ -203,7 +202,7 @@ static int test_session_handler(request_
> >  return DECLINED;
> >
> >  /* Copy the header for SessionHeader from the request to the
> response. */
> > -if (overrides = apr_table_get(r->headers_in, TEST_SESSION_HEADER))
> > +if ((overrides = apr_table_get(r->headers_in, TEST_SESSION_HEADER)))
> >  apr_table_setn(r->headers_out, TEST_SESSION_HEADER, overrides);
> >
> >  /* Additional commands to test the session API via POST. */
> > @@ -240,15 +239,15 @@ static int test_session_handler(request_
> >  }
> >  else if (!strcmp(pair->name, "name")) {
> >  apr_size_t len;
> > -apr_brigade_length(pair->value, 1, );
> > +apr_brigade_length(pair->value, 1, (apr_off_t *));
> >
> > This seems really dangerous. Aren't there cases where sizeof(apr_size_t)
> != sizeof(apr_off_t) ??
> >
> >  fieldName = apr_pcalloc(r->pool, sizeof(char) * len +
> 1);
> > -result = apr_brigade_flatten(pair->value, fieldName,
> );
> > +result = apr_brigade_flatten(pair->value, fieldName,
> (apr_size_t *));
> >
> > This seems unnecessary.  should already be apr_size_t *
> >
> >  }
> >  else if (!strcmp(pair->name, "value")) {
> >  apr_size_t len;
> > -apr_brigade_length(pair->value, 1, );
> > +apr_brigade_length(pair->value, 1, (apr_off_t *));
> >  fieldValue = apr_pcalloc(r->pool, sizeof(char) * len +
> 1);
> > -result = apr_brigade_flatten(pair->value, fieldValue,
> );
> > +result = apr_brigade_flatten(pair->value, fieldValue,
> (apr_size_t *));
> >
> > These two, same as above.
> >
> > Heh. I haven't reviewed httpd code for years. But I saw a change to
> mod_authany.c and thought "what is that? isn't that module crazy stable?"
> ... curiosity :-P
> >
> > Cheers,
> > -g
> >
>
>

Re: mod_ssl namespacing: app_data2

[Greg Stein]

On Fri, May 1, 2015 at 8:58 AM, Stefan Sperling s...@apache.org wrote:
...

 So modssl_ has been agreed on? :)


It hasn't been agreed. Just not denied. Yet.

:-P

Re: Change of web site layout

[Greg Stein]

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.

Cheers,
-g



On Sun, Jun 15, 2014 at 3:55 PM, Daniel Gruno 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.

Re: Change of web site layout

[Greg Stein]

On Mon, Jun 16, 2014 at 3:00 AM, André Malo 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.

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

[Greg Stein]

On Mon, Jun 16, 2014 at 3:54 AM, Daniel Gruno rum...@cord.dk wrote:

 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?


There ya go! ... things that aren't part of my task-at-hand (why did I
come here? what am I looking for?). A carousel hides that. But...
supplemental stuff.. sure.

Or to rephrase: I have landed at the page with a goal in mind. How fast can
the page satisfy my need? A carousel holding *my* needed information cannot.

But yes: it does liven up the page, and it can certainly provide some info
that I may have not thought about, or been seeking.

Thanks,
-g

Re: [PATCH PR55304] mod_dav: COPY should not validate the parent of request.

[Greg Stein]

Fixed in r1506714, and proposed for backport to 2.2.x and 2.4.x.

On Wed, Jul 24, 2013 at 3:38 PM, Ben Reser b...@reser.org wrote:
 This patch fixes a regression created by the PR54610.  COPY does not
 modify the parent of the source, so it should not be validating the
 parent.  This issue actually disallows the ability to COPY the root of
 a DAV repository since a properly implemented DAV provider will return
 NULL and dav_method_copymove() will error on that.

 We ran into this with Subversion, which actually revealed a security
 issue with our implementation of get_parent_resource() since it failed
 on the root.  But beyond that we realized we were not properly
 returning NULL for some resources when the resource is the root and
 thus has no parent.  If we fix this without this patch being made to
 mod_dav then HTTP 2.2.25 and 2.4.6 will lose the ability to COPY the
 root.

 If someone can apply it that would be appreciated.  It's certainly
 been looked at by several eyes over on the Subversion side.

Re: trunk/mod_ssl and Windows

[Greg Stein]

Gee, thanks for the education.

And I will continue to top-post. Deal with it.
On Feb 3, 2013 3:16 AM, Nick Kew n...@webthing.com wrote:


 On 3 Feb 2013, at 07:53, Greg Stein wrote:

 A: It reverses the normal flow of conversation.
 Q: What is wrong with top-posting?

  Whatever happened to Commit-Then-Review?!

 That's a judgement for the committer, suitable when the committer
 doesn't feel notice or discussion is required.  You may think Gregg
 is being over-diffident, but that's his right.  Nothing to lose by erring
 on the side of caution.

  Are there any objections to this

 Seems unlikely.

 --
 Nick Kew

Re: trunk/mod_ssl and Windows

[Greg Stein]

Whatever happened to Commit-Then-Review?!
On Feb 2, 2013 4:18 PM, Gregg Smith g...@gknw.net wrote:

 Hello,

 Since the Next Protocol Negotiation addition, mod_ssl cannot be compiled on
 Windows since the AP namespace is for imports.

 Are there any objections to this which allows the NPN hooks to be exported
 in
 Windows.

 If there are no objection I'll commit this in a few days.

 Regards,

 Gregg

Re: If-Match not supported with PROPFIND?

[Greg Stein]

On Mon, Sep 24, 2012 at 10:38 PM, Timothy Wood t...@omnigroup.com wrote:

 My reading of the WebDAV spec leads me to believe that PROPFIND should 
 support If-Match, but trying it and looking at the code for 
 dav_method_propfind() I don't see a call to dav_validate_request(), 
 dav_meets_conditions() or ap_meets_conditions().

You're right! Looks like I totally spaced on a call to
dav_validate_request() for PROPFIND.


 Is my reading of the spec incorrect, or is this an oversight? I guess I'll 
 work up a patch!

As Julian stated, that stuff really should move out of mod_dav and
into the core httpd to apply to all requests (ie. likely move all the
logic into ap_meets_conditions). But at a minimum, you should be able
to fix it for PROPFIND. Be wary, though: I suspect that you're going
to need to perform the validation in the *walker*. ie. the If- headers
would apply to all resources touched by the request (caused by the
Depth: header).

Cheers,
-g

Re: [users@httpd] Why does a DELETE transaction check for locks on Parent Collection

[Greg Stein]

The parent collection is modified as a result of the DELETE (a
resource is removed from the set). Thus, the parent requirements must
be met.

On Wed, Sep 26, 2012 at 8:35 PM, Jeff Trawick traw...@gmail.com wrote:
 adding dev@...

 On Wed, Sep 26, 2012 at 4:53 PM, Bennett, Tony bennett.t...@con-way.com 
 wrote:
 Environment:
 Version:2.2.16
 Platform OS:AIX 6.1
 Configuration:  WebDav enabled
 Client: Windows 7 Mapped Network Drive

 Here is the interaction:

 Client  sends a PUT
 Server  responds with a 200
 Client  sends a LOCK request
 Server  responds with a 200 and this header is in the response:
 Lock-Token: 
 opaquelocktoken:f86e1996-0726-11e2-b22c-c30f656528a6
 Client  sends a DELETE and includes this header in the request:
 If: (opaquelocktoken:f86e1996-0726-11e2-b22c-c30f656528a6)
 Server  responds with a 424 Failed Dependency and includes this text in its 
 response body:
?xml version=1.0 encoding=utf-8?
D:multistatus xmlns:D=DAV:
D:response
D:href/TEST_DIR/D:href
D:statusHTTP/1.1 412 Precondition Failed/D:status
D:responsedescriptionA validation error has occurred on the parent 
 resource,
preventing the operation on the resource specified by the 
 Request-URI. The error was:
The precondition(s) specified by the If: header did not match this 
 resource. At
least one failure is because: a State-token was supplied, but it was 
 not found in the
locks on this resource./D:responsedescription
/D:response
/D:multistatus

 Here is a subset of the Apache Error Log:
   Could not DELETE /TEST_DIR/~$EXCEL_File.xlsx due to a failed 
 precondition (e.g. locks).  [424, #0]
  (11)Resource temporarily unavailable: An error occurred on another 
 resource, preventing the requested operation on this resource.  [424, #0]

 I tried locking/deleting with cadaver, which worked it had a slightly 
 different If header:
  If: http://dmsa.con-way.com/TEST_DIR/~%24EXCEL_File.xlsx 
 (opaquelocktoken:fec89268-081a-11e2-a1d7-c30f65659e0a)

 My question is why did Apache check for the opaquetoken against the parent 
 collection when the request came from Win7...???

 I can't find a requirement to do so in the standard (RFC2518 or RFC4918).

 NOTE:  I tried locking/deleting with cadaver, which worked it had a 
 slightly different If header:
  If: http://dmsa.con-way.com/TEST_DIR/~%24EXCEL_File.xlsx 
 (opaquelocktoken:fec89268-081a-11e2-a1d7-c30f65659e0a)

 Any insight would be helpful.

 -tony


 -
 To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
 For additional commands, e-mail: users-h...@httpd.apache.org




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

Re: [users@httpd] Why does a DELETE transaction check for locks on Parent Collection

[Greg Stein]

dev@ people: my post bounced from users@ since I'm not subscribed
there. IOW, Tony and others didn't see my response...

On Wed, Sep 26, 2012 at 8:41 PM, Greg Stein gst...@gmail.com wrote:
 The parent collection is modified as a result of the DELETE (a
 resource is removed from the set). Thus, the parent requirements must
 be met.

 On Wed, Sep 26, 2012 at 8:35 PM, Jeff Trawick traw...@gmail.com wrote:
 adding dev@...

 On Wed, Sep 26, 2012 at 4:53 PM, Bennett, Tony bennett.t...@con-way.com 
 wrote:
 Environment:
 Version:2.2.16
 Platform OS:AIX 6.1
 Configuration:  WebDav enabled
 Client: Windows 7 Mapped Network Drive

 Here is the interaction:

 Client  sends a PUT
 Server  responds with a 200
 Client  sends a LOCK request
 Server  responds with a 200 and this header is in the response:
 Lock-Token: 
 opaquelocktoken:f86e1996-0726-11e2-b22c-c30f656528a6
 Client  sends a DELETE and includes this header in the request:
 If: (opaquelocktoken:f86e1996-0726-11e2-b22c-c30f656528a6)
 Server  responds with a 424 Failed Dependency and includes this text in its 
 response body:
?xml version=1.0 encoding=utf-8?
D:multistatus xmlns:D=DAV:
D:response
D:href/TEST_DIR/D:href
D:statusHTTP/1.1 412 Precondition Failed/D:status
D:responsedescriptionA validation error has occurred on the parent 
 resource,
preventing the operation on the resource specified by the 
 Request-URI. The error was:
The precondition(s) specified by the If: header did not match this 
 resource. At
least one failure is because: a State-token was supplied, but it was 
 not found in the
locks on this resource./D:responsedescription
/D:response
/D:multistatus

 Here is a subset of the Apache Error Log:
   Could not DELETE /TEST_DIR/~$EXCEL_File.xlsx due to a failed 
 precondition (e.g. locks).  [424, #0]
  (11)Resource temporarily unavailable: An error occurred on another 
 resource, preventing the requested operation on this resource.  [424, #0]

 I tried locking/deleting with cadaver, which worked it had a slightly 
 different If header:
  If: http://dmsa.con-way.com/TEST_DIR/~%24EXCEL_File.xlsx 
 (opaquelocktoken:fec89268-081a-11e2-a1d7-c30f65659e0a)

 My question is why did Apache check for the opaquetoken against the 
 parent collection when the request came from Win7...???

 I can't find a requirement to do so in the standard (RFC2518 or RFC4918).

 NOTE:  I tried locking/deleting with cadaver, which worked it had a 
 slightly different If header:
  If: http://dmsa.con-way.com/TEST_DIR/~%24EXCEL_File.xlsx 
 (opaquelocktoken:fec89268-081a-11e2-a1d7-c30f65659e0a)

 Any insight would be helpful.

 -tony


 -
 To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
 For additional commands, e-mail: users-h...@httpd.apache.org




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

Re: DNT IE10 (was svn commit: r1371878 - /httpd/httpd/trunk/docs/conf/httpd.conf.in)

[Greg Stein]

On Sep 13, 2012 7:48 AM, Eric Covener cove...@gmail.com wrote:

 On Sat, Aug 11, 2012 at 3:51 AM,  field...@apache.org wrote:
  Author: fielding
  Date: Sat Aug 11 07:51:52 2012
  New Revision: 1371878
 
  URL: http://svn.apache.org/viewvc?rev=1371878view=rev
  Log:
  Apache does not tolerate deliberate abuse of open standards

 I've come around on this one over time.  While I appreciate the
 message/intent, I don't think this is reasonable for the default
 configuration because it errs on the side of ditching a privacy header
 and information loss for a (sensitive) header that we're not yet
 interpreting.  IMO it's enough even without this specific DNT text:

 An HTTP intermediary must not add, delete, or modify the DNT header
 field in requests forwarded through that intermediary unless that
 intermediary has been specifically installed or configured to do so by
 the user making the requests. For example, an Internet Service
 Provider must not inject DNT: 1 on behalf of all of their users who
 have not selected a choice.

 I'd like to revert it, but this is not yet a veto.  I'd like to hear
 what others think and would appreciate an ACK from Roy/Greg/Jim who
 voted for the backport to avoid any churn.

Microsoft is putting their users at risk, not us. I believe the change
should remain.

Re: DavGenericLockDB scope - what should it be?

[Greg Stein]

The docs are correct. There shouldn't be any real problem with a
server-wide database.

Cheers,
-g
On Jul 25, 2012 7:36 AM, Graham Leggett minf...@sharp.fm wrote:

 Hi all,

 According to the docs at
 http://httpd.apache.org/docs/2.4/mod/mod_dav_lock.html#davgenericlockdbthe 
 scope of the DavGenericLockDB is server config, virtual host,
 directory.

 According to the source, the scope is inside Directory or Location as
 follows:

 AP_INIT_TAKE1(DAVGenericLockDB, dav_lock_cmd_davlockdb, NULL,
 ACCESS_CONF,
   specify a lock database),

 Can anyone confirm which one is supposed to be correct?

 Regards,
 Graham
 --

Re: svnmerge.py (Was: Re: mergeinfo ignorance)

[Greg Stein]

Nah... obsoleted by merge tracking (svn:mergeinfo) with the svn 1.5 release.

Please ignore that script and use svn merge.

And also that svn is a TLP sibling nowadays can surely help :-)

Cheers,
-g
On Jul 23, 2012 10:56 AM, Jim Jagielski j...@jagunet.com wrote:

 Is this still useful: svnmerge.py ?

 http://www.orcaware.com/svn/wiki/Svnmerge.py

 On Jul 23, 2012, at 8:45 AM, Jim Jagielski wrote:

  I for sure don't use 'svn merge' and am likely guilty (and the
  orig post clearly indicates) of this... For awhile, svn merge
  was as wonky as hell, so I simply skipped using it and instead
  used the svn.merge script which, for the curious, does a simple
  diff and patch.
 
  I'm guessing that things are better now ;)
 
  On Jul 22, 2012, at 12:12 PM, Rainer Jung wrote:
 
  On 22.07.2012 16:59, Eric Covener wrote:
  CAUTION:
 
  Always merge into a clean branch checkout and commit the whole
 branch. If
  you start to only commit parts of the branch after merging, svn will
 produce
  additional mergeinfo properties attached to sub directories or files.
 We
  don't want that.
 
 
  I might be a culprit here, I use someones svn.merge script in a not so
  clean checkout but then checkin individual files.  Will work on it.
 
  No culprit. At least in 2.4.x there is currently only one mergeinfo,
 all is fine :)
 
  Regards,
 
  Rainer
 
 

Re: TRACE still enabled by default

[Greg Stein]

On Wed, Mar 21, 2012 at 15:59, Mark Montague m...@catseye.org wrote:
 On March 21, 2012 15:33 , Roy T. Fielding field...@gbiv.com wrote:

 TRACE won't work at all if the most popular end-point doesn't support it.

 Why would this be a bad thing?  Or, to phrase it another way, what are the
 situations in which it is desirable that TRACE be already-enabled on a web
 server as opposed to having the owner of the web server enable the TRACE
 method in response to a specific debugging need?

Roy means that if we don't set the precedent for TRACE being present
and how it is supposed to work, then nobody else will. The Apache HTTP
server is effectively the embodiment and leader of the HTTP
specification.

Cheers,
-g

Re: TRACE still enabled by default

[Greg Stein]

On Wed, Mar 21, 2012 at 16:23, Reindl Harald h.rei...@thelounge.net wrote:
 Am 21.03.2012 21:02, schrieb Greg Stein:
 On Wed, Mar 21, 2012 at 15:59, Mark Montague m...@catseye.org wrote:
 On March 21, 2012 15:33 , Roy T. Fielding field...@gbiv.com wrote:

 TRACE won't work at all if the most popular end-point doesn't support it.

 Why would this be a bad thing?  Or, to phrase it another way, what are the
 situations in which it is desirable that TRACE be already-enabled on a web
 server as opposed to having the owner of the web server enable the TRACE
 method in response to a specific debugging need?

 Roy means that if we don't set the precedent for TRACE being present
 and how it is supposed to work, then nobody else will. The Apache HTTP
 server is effectively the embodiment and leader of the HTTP
 specification.

 and now tell us ONE real world reason to
 enable it BY DEFAULT

Don't get ALL-CAPS angry at me. There's no call for that. It just
seemed that Mark wasn't understanding Roy's comment, so I tried to
elucidate.

-g

Re: SVN question (Was: Re: log-message-tags)

[Greg Stein]

svn:externals is only a client-side mechanism. This will not bring
log-message-tags/ into the branch, and especially not within the tag.

In essence, you will not be able to recreate any specific state in
time (or a release!) because of this. The repository doesn't actually
reflect the state that you're trying to capture.

You could construct a tarball for 2.4.x, but a week later, that
tarball cannot be reconstructed. The checksums will not match. etc.

My suggestion would be to add a step to the TR instructions to do a
merge from trunk over to the branch before processing a release. Thus,
the branch will get a snapshot of the log-message-tags at the time of
release.

Cheers,
-g

On Wed, Mar 7, 2012 at 06:33, Jim Jagielski j...@jagunet.com wrote:
 Never mind, I hope I did it correctly :)

   % cat la
   log-message-tags 
 https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/log-message-tags
   % pwd
   blahblah.../dev/httpd-2.4/docs
   % svn propset svn:externals . -F la
   property 'svn:externals' set on '.'
   % svn up
   Fetching external item into 'log-message-tags':
   A    log-message-tags/update-log-msg-tags
   A    log-message-tags/find-messages.cocci
   A    log-message-tags/next-number
   A    log-message-tags/macros.h
   A    log-message-tags/README
   Updated external to revision 1297944.


 On Mar 7, 2012, at 6:27 AM, Jim Jagielski wrote:

 A question for SVN experts: can we create an export or something like
 that that puts the trunk version of docs/log-message-tags/ in
 the 2.4 branch, so that there exists only 1 canonical version
 and it lives in trunk but is referred to in the 2.4 branch?
 On Mar 6, 2012, at 7:43 PM, Rainer Jung wrote:

 hi Jim,

 On 07.03.2012 00:24, Jim Jagielski wrote:
 Oh yeah... and how do we worry about keeping things in sync. For
 example, right now trunk uses 02298 and 02299, but 2.4 does not.
 When another log entry is added to 2.4, do we use these or skip
 these???

 On Mar 6, 2012, at 6:21 PM, Jim Jagielski wrote:

 Hmmm... anyone else noticing that the httpd-2.4 branch is lacking
 the docs/log-message-tags/ dir?

 I asked the question in the Questions thread end of January:

 2) log tags
 ===

 r1209743 | sf | 2011-12-02 23:26:54 +0100 (Fri, 02 Dec 2011) | 3
 lines Add APLOGNO() macro for unique tags for every log message.
 Add some scripts to make adding these tags easier.

 This has only been backported partially. The directory
 docs/log-message-tags is mising in 2.4.x as well as the
 update-log-tags and update-log-msg-tags targets in Makefile.

 Stefan answered on Jan. 31st:

 This is intentional and not for backport. The log tags should be
 consistent between trunk and the branches, so there can be only one
 docs/log-message-tags/next-number file, and that resides in trunk.
 That means if an error message is introduced in 2.4 but not in trunk,
 the next-number file in trunk should be updated.

 But there should probably be a docs/log-message-tags/README file in
 2.4 that explains this. I will write something when I have time. But
 as a non-code change, this is not that urgent.

 Regards,

 Rainer

Re: SVN question (Was: Re: log-message-tags)

[Greg Stein]

2012/3/7 Igor Galić i.ga...@brainsware.org:


 - Original Message -
 svn:externals is only a client-side mechanism. This will not bring
 log-message-tags/ into the branch, and especially not within the tag.

 In essence, you will not be able to recreate any specific state in
 time (or a release!) because of this. The repository doesn't actually
 reflect the state that you're trying to capture.

 You could construct a tarball for 2.4.x, but a week later, that
 tarball cannot be reconstructed. The checksums will not match. etc.

 Huh?

 svn externals can reference a specific revision.

With recent versions of Subversion, sure. But regardless, look at
Jim's copy/paste. There is no pegged revision.

Cheers,
-g

Re: SVN question (Was: Re: log-message-tags)

[Greg Stein]

On Wed, Mar 7, 2012 at 06:59, Jim Jagielski j...@jagunet.com wrote:

 On Mar 7, 2012, at 6:40 AM, Greg Stein wrote:

 svn:externals is only a client-side mechanism. This will not bring
 log-message-tags/ into the branch, and especially not within the tag.


 Which is fine... docs/log-message-tags isn't part of the
 releasable data for a branch anyway. It's a developer artifact
 only.

Ah! Then the externals solution is Just Fine!

Cheers,
-g

Re: [RE-VOTE #2] adoption of mod_policy subproject

[Greg Stein]

On Fri, Mar 2, 2012 at 14:42, Stefan Fritsch s...@sfritsch.de wrote:
 On Friday 02 March 2012, William A. Rowe Jr. wrote:
 A proposal to adopt mod_policy is attached.

   [ ] Option 1: adopt as trunk module

 +1 to option 1

+1 to option 1.

Re: Technical reasons for -1 votes (?)

[Greg Stein]

On Mar 1, 2012 12:20 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote:
...
 If there are two other committers who will vote with Jim for this
 project to accept one or more of these modules into trunk (rather than
 subproject), and someone will finish the ip-clearance, I'm great with
 that.  If none of that happens I will revert this mess.

I support Jim. +1

Re: [RE-VOTE] adoption of mod_firehose MODULE

[Greg Stein]

On Mar 1, 2012 1:29 PM, Jim Jagielski j...@jagunet.com wrote:


 On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote:

  Let's simply reset this whole mess.
 
  A proposal to adopt mod_firehose is attached.
 
   [X] Option 1: adopt as trunk module
   [ ] Option 2: adopt only as subproject
   [ ] Option 3: do not adopt

+1 for Option 1.

Re: [RE-VOTE] adoption of mod_firehose MODULE

[Greg Stein]

Modules do not have to be tested *before* they appear in trunk. That's
putting the cart before the horse. Part of the development process
(while in trunk) is doing the testing portion. And hey... if it never
gets tested, then it gets marked as experimental and we all move on.

Cheers,
-g

On Thu, Mar 1, 2012 at 15:05, Michael Felt mamf...@gmail.com wrote:
 Seems dangerous to even comment in this flow - but as I am all about
 thinking testing at the moment - is there any thought about how to test
 this. From a packaging point of view I would expect tooling to be able to
 test are included functions. As a user I would expect anything in trunk
 (what I would call main) to be guaranteed.

 I cannot have an opinion about the reasoning for placing something in, or
 not in trunk, and I would expect something to at least have gone through
 some sort of testing process - live testing - before committing anything to
 a product/service. Before testing was completed I would only dare speaking
 of an intention to add.

 Isnt it something along the lines of: The proof of the pudding is the
 eating.

 To me this is just mod_foo, and as far as I know it has never been tested.
 (If it is already in trunk maybe I have already compiled it and just do not
 know it :p) - and that alone would make me postpone a non-reversible
 decision.

 Makes me think of what someone old and wise said to me when I was young: you
 (or she) only has to say Yes, or even (yes) once.


 On Thu, Mar 1, 2012 at 8:33 PM, Greg Stein gst...@gmail.com wrote:


 On Mar 1, 2012 1:29 PM, Jim Jagielski j...@jagunet.com wrote:
 
 
  On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote:
 
   Let's simply reset this whole mess.
  
   A proposal to adopt mod_firehose is attached.
  
    [X] Option 1: adopt as trunk module
    [ ] Option 2: adopt only as subproject
    [ ] Option 3: do not adopt

 +1 for Option 1.

Re: [RE-VOTE] adoption of mod_firehose MODULE

[Greg Stein]

On Thu, Mar 1, 2012 at 16:30, Rich Bowen rbo...@rcbowen.com wrote:
...
 I've often thought that modules like, say, mod_ftp, would have a much
 greater chance of being successful if they were in trunk rather than it
 being several additional steps to obtain.

 I'm +1 to having this in trunk, but am voting based on the community
 aspects, rather than the technical ones. I figure the technical aspects will
 work themselves out in trunk ... or they won't, and we'll drop it from a
 release branch.

Exactly. In the subversion project, we always strive to do development
directly on trunk (rather than branches). Keeping stuff in trunk gives
it many more eyeballs and testing. New features might be buggy on
trunk, but just don't use it yet is a good response :-)

Cheers,
-g

Re: IP Clearance? NAK

[Greg Stein]

On Thu, Mar 1, 2012 at 20:52, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 3/1/2012 4:17 PM, Roy T. Fielding wrote:
 On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote:

 Perhaps you are signing up to do that ip-clearance, since it doesn't
 seem to be coming from the committer.

 IP clearance for an existing committer is BULLSHIT.  I already cleared
 that with Legal when I was chair of this project.

 Somehow, having chaired the HTTP Server project for 2 years, I had missed
 the memo.  This information is not being communicated.  Thank you for
 enlightening me, our chair Eric, and the rest of the TLP communities.

 The HTTP Server Project will proceed to ignore the IP Clearance process
 laid out by the Incubator for all incoming contributions from any actual
 project committer or their employer, until informed otherwise by the
 President of the foundation.

Why don't you stop with your passive-aggressive bullshit, and read the
thread over on legal-discuss where we talked about fixing the short
form IP Clearance process. The IP policies have not changed, but they
*should*, along the lines Roy suggests in that thread.

The HTTP PMC cannot ignore the clearance process. But we do need to
fix the process. And we don't need your crap.

-g

Re: Apache 2.4.1 Throughput compared with nginx

[Greg Stein]

Google Translate :-)

On Fri, Feb 24, 2012 at 01:06, dreamice dreamice.ji...@gmail.com wrote:
 could you write it in English?


 2012/2/24 MATSUMOTO Ryosuke matsu1...@gmail.com

 Hi all,

 I evaluated the throughput of Apaceh 2.4.1. I compared apache(2.4.1,
 2.2.3) with nginx.
 I used httperf benchmark 0.9.0 to measure thethroughput.

 http://blog.matsumoto-r.jp/?p=1812

 I feel bad about writing this article in Japanese in my hurry ;)

 Regards,
 --
 MATSUMOTO Ryosuke  matsu1229 at gmail.com 
 http://blog.matsumoto-r.jp/

Re: [VOTE] Bundle apr/apu with 2.4.x

[Greg Stein]

On Feb 2, 2012 12:01 PM, Nick Kew n...@webthing.com wrote:

 On Thu, 2 Feb 2012 09:54:02 -0500
 Jim Jagielski j...@jagunet.com wrote:


[*] -1: Do not bundle apr/apu with Apache httpd 2.4.x
 
  Cheers!

 Those users who might have difficulty with an unbundled package
 aren't likely to be installing from our tarballs.  That's what
 downstream packagers are for.

Agreed.

-1

Re: WebDAV and ACL (RFC3744), status?

[Greg Stein]

Yeah: mod_dav itself has no direct support for ACLs.

Way back when, when I wrote mod_dav and was working on DAV stuff in
general, the ACL stuff created an interesting problem: how to
propagate access control changes to all the httpd processes. If the
processes do not contain the ACLs, then the implication is a query on
each(!) request. That made me a bit uncomfortable, and I never pursued
it much further.

It may be fair to say that servers today (compared to a decade ago,
when I worked on this stuff) are highly overpowered relative to the
network bandwidth, and this kind of dynamic ACL query is not a problem
any more.

Cheers,
-g

On Wed, Feb 1, 2012 at 10:53, Brian J. France br...@brianfrance.com wrote:
 I had started breaking up the patches from mod_dav_acl into smaller chunks 
 and getting them imported into the trunk.

 My goal was to get a mod_dav_acl like module added.  I say like because 
 mod_dav_acl currently requires xfs and stores the auth information in the xfs 
 attributes and I wanted to create a more authn type module.  Something that 
 could have a flat file, dbm, dbd, etc type plugins.

 After mod_dav_acl was done I wanted to get mod_caldav and mod_cardav imported 
 as well, but free time dried up and I never finished.

 Brian


 On Feb 1, 2012, at 10:38 AM, Andreas wrote:

 Good evening.

 Where can I find out if httpd/mod_dav has support for ACL's?

 After digging in the mailinglist, there seem to have been some activity
 about the topic in 2007 and 2009 but no patches seem to be applied.

 I checked today on 2.3beta, there is no --enable-dav-acl option yet
 (unless enabled by default?).

 I could not find any bugzilla issue tracking the patches either, so now
 I ask here as a last resort if anyone knows status on it. :)


 Regards
 --
 Andreas

  ... Mental backup in progress - Do Not Disturb!

Re: APR hash vs httpd implementation

[Greg Stein]

I think that question is best answered by the people who develop
mod_cache, aka dev@httpd.apache.org.

That said, I'll offer a guess: that is along-lived hash table that
will see plenty of churn over time. An APR hash table would continue
to grow and consume memory, but you really don't want that to occur in
mod_cache. Thus, to keep memory reasonably constrained, it avoids
using pools.

Cheers,
-g

On Mon, Dec 5, 2011 at 13:52, sridhar basam s...@basam.org wrote:

 Anyone know why the mod_cache code has an almost identical implementation of
 the apr_hash* functions? Seems like the only difference is that the
 mod_cache implementation isn't using APR pools and has a fixed size  table.
 Are there any advantages using one over the other?

 thanks,
            Sridhar

Re: Limited connectivity

[Greg Stein]

It's been nearly two weeks, and we can't block on individuals like this. I
think it was the right move.

Cheers,
-g
On Jul 23, 2011 1:51 PM, Stefan Fritsch s...@sfritsch.de wrote:
 On Sunday 17 July 2011, William A. Rowe Jr. wrote:
 On 7/17/2011 8:30 AM, Jim Jagielski wrote:
  Hey Bill, was wondering how this is coming...
 
  On Jul 12, 2011, at 11:46 PM, William A. Rowe Jr. wrote:
  Just to let folks know, I won't be able to roll back our patches
  and sandbox them until I have something resembling stable
  connectivity, and it may be a day or two before that happens.

 I should be caught up on work later this afternoon, and jumping
 into the httpd svn tree trimming project (much easier than the
 storm damaged tree trimming projects of last week). So expect
 this to be wrapped up later today.

 Sorry for being impatient, but I have now reverted it. You don't seem
 to have enough time ATM and I think this was delaying the next beta.

Re: [vote] mod_ldap

[Greg Stein]

On Tue, Jul 12, 2011 at 00:02, William A. Rowe Jr. wr...@rowe-clan.net wrote:
...
 Which should be the combined revert of

 http://svn.apache.org/viewvc?view=revisionrevision=1143225
 http://svn.apache.org/viewvc?view=revisionrevision=1143222
 http://svn.apache.org/viewvc?view=revisionrevision=1143221
 http://svn.apache.org/viewvc?view=revisionrevision=1141203
 http://svn.apache.org/viewvc?view=revisionrevision=1141201
 http://svn.apache.org/viewvc?view=revisionrevision=1140075
 http://svn.apache.org/viewvc?view=revisionrevision=1140069
 http://svn.apache.org/viewvc?view=revisionrevision=1130186
 http://svn.apache.org/viewvc?view=revisionrevision=1131393
 http://svn.apache.org/viewvc?view=revisionrevision=1129956
 http://svn.apache.org/viewvc?view=revisionrevision=1129891
 http://svn.apache.org/viewvc?view=revisionrevision=1129886
 http://svn.apache.org/viewvc?view=revisionrevision=1129808

 Sorry, I don't see applying a mega-revert.  Either piecemeal
 or wholesale svn cp's from pre-1129808 seems more sensible.
 The later is more legible in svn, because re-applying the
 commits with proper attribution would be messy.

'svn cp' can be dangerous... you may wipe out other, unrelated changes.

From a version control aspect, you also lose the information that the
(above) revisions were reverse-merged (aka reverted). But I would
simply state that is a pedantic detail, and the revert process should
use whatever is easiest. If you go with 'svn cp', then just check the
logs on the target files to ensure you don't lose unrelated changes.

Cheers,
-g

Re: svn commit: r1103315 - /httpd/httpd/trunk/modules/filters/mod_deflate.c

[Greg Stein]

On Wed, May 25, 2011 at 02:53, Ruediger Pluem rpl...@apache.org wrote:
...
 Thanks. IMHO this is a design flaw in the DAV provider API in conjunction
 with the current filter API:

  dav_error * (*deliver)(const dav_resource *resource,
                           ap_filter_t *output);

 deliver is usually called with r-output_filters as a second parameter and
 thus makes a copy of the contents of r-output_filters and hence does not
 notice if r-output_filters changes during the process of pushing content thru
 the filter chain by multiple calls to ap_pass_brigade.

Yup...

 My idea would be to change the DAV API to either

 dav_error * (*deliver)(const dav_resource *resource,
                           request_rec *r);

 and using r-output_filters in the implementations of the deliver method in

I chose not to do it this way because I wanted to isolate the DAV
providers as much as possible from the request_rec. The idea was to
keep them relatively independent of the fact that the provider is
operating within an HTTP server. Passing r-output_filter was a much
narrower view than passing the entire request_rec. The request_rec
has got a LOT of exposure to the innards of the server, and I didn't
want providers to worry about that, and certainly not to muck around
with it and do funny things.

Obviously, that approach has now caused a problem where you have
filter that want to remove themselves. I would posit that even if you
solve the mod_dav case, that the problem would *still* exist. Other
content generators might grab r-output_filters at the beginning of
their operation, and then never notice a change in the request_rec.
mod_dav does this, but how do we know that others do not?

Cheers,
-g

Re: blocking Upgrade

[Greg Stein]

On Wed, Mar 30, 2011 at 11:08, Graham Leggett minf...@sharp.fm wrote:
 On 30 Mar 2011, at 4:41 PM, Roy T. Fielding wrote:

 My guess is that it would if it were told to use a proxy for ws.

 Keep in mind that when I say proxy, I do not mean to include reverse
 proxy.
 A reverse proxy of websockets is just an implementation of websockets or
 a tunnel.  I consider both to be pretty dangerous and better done in
 a special-purpose server rather than as a child of Apache httpd.

 When you say pretty dangerous, are you referring to the danger of reaching
 the limit of slots willing to be served by the server, or something else?

 I would say that any server that supports the idea of long lived connections
 faces this danger, I don't see why httpd (suitably and sensibly configured
 obviously, probably with an event mpm and a limit as to the number of slots
 we allow to be long lived) can't play too.

I think that Roy's point is simply that httpd would be nothing more
than a socket-listener and tunnel. There is very little that it can
bring to the table at that point, so it doesn't make a lot of sense to
lump in websockets capabilities.

Cheers,
-g

Re: blocking Upgrade

[Greg Stein]

Do you have an internet draft spec for some context here? Is there a
proposal for HTTP/2.0?

I might also argue that a directive is not the right answer here.
Instead, I'd suggest that modules advertise their ability to consume
protocols. If an Upgrade arrives, and a relevant module is found, then
the request is handled. If no such module is found, then the Upgrade
header is ignored, and nothing happens.˛˛

If a module or CGI sees the Upgrade header, then what is the problem?
It cannot truly alter the protocol in effect for the connection. That
seems to be something only possible to handle within the core (to
change the connection handler).

And back to the AllowUpgrade directive. What the heck should it do
if something is present *besides* none. It isn't like that can be
handled. Some code must be written to provide other protocols, and
*that* code should manage the tokens recognized. Not a directive.

Cheers,
-g

On Tue, Mar 29, 2011 at 17:04, Roy T. Fielding field...@gbiv.com wrote:
 Does anyone with a working install want a quick project?

 We need to block the Upgrade header field by default.  What this
 will require is a new configuration command, like

   AllowUpgrade None | word ...

 where word is any protocol name, like HTTP/2.0, waka, websocket, etc.
 The config command must only be allowed in rsrc_conf.

 We then need a check somewhere in the http filter for an incoming
 request header field called Upgrade.  If present and the config option
 is set to None (or default), then remove the Upgrade field before it
 is seen by the request handler (i.e., before it might be used by some
 module or CGI script to send the server down a rat hole).
 If the config option is set and not None, then set the Upgrade
 header field-value to be the intersection of what was sent by the
 client and what is allowed by the config.

 Likewise, perform the same filtering on outbound responses.

 In other words, only allow a handler to upgrade the connection
 if it has been explicitly configured by the main server config
 to be an okay thing to do.

 Any takers?  If not, I'll give it a try next week when I am back
 from the IETF.

 Roy

Re: blocking Upgrade

[Greg Stein]

On Mar 29, 2011 5:35 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote:

 On 3/29/2011 4:16 PM, Greg Stein wrote:
  Do you have an internet draft spec for some context here? Is there a
  proposal for HTTP/2.0?
 
  I might also argue that a directive is not the right answer here.
  Instead, I'd suggest that modules advertise their ability to consume
  protocols. If an Upgrade arrives, and a relevant module is found, then
  the request is handled. If no such module is found, then the Upgrade
  header is ignored, and nothing happens.˛˛
 
  If a module or CGI sees the Upgrade header, then what is the problem?
  It cannot truly alter the protocol in effect for the connection. That
  seems to be something only possible to handle within the core (to
  change the connection handler).
 
  And back to the AllowUpgrade directive. What the heck should it do
  if something is present *besides* none. It isn't like that can be
  handled. Some code must be written to provide other protocols, and
  *that* code should manage the tokens recognized. Not a directive.

 Agreed, we already have a single example case; in the presence of the
 'SSLEngine optional' directive, which consumes the Upgrade: TLS/1.0
 given Connection: Upgrade

 All such handlers must respond with a 101 Switching Protocols.

 So if we don't see the resulting Upgrade: TLS/1.0, HTTP/1.1 response
 header, we can easily short circuit any further response in the core
 handler.  The mechanics of this could be simplified, but I'd suggest
 we start by stealing code from mod_ssl's upgrade handler.

 The only remaining system administration decision is allow or refuse
 unrecognized Upgrade requests?  The recognition of specific upgrade
 headers is up to the installed modules and their specific configurations.

Note that the client-sent Upgrade header can be completely disregarded by
the server:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42

I'm not sure that we have anything mandatory to do here. I think the correct
answer is to provide connection-layer protocol handling pass-offs.

I don't see how a directive assists here.

Cheers,
-g

Re: Prior to apr 2.0 / httpd 2.4...

[Greg Stein]

On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 3/20/2011 7:43 PM, Dan Poirier wrote:
 On Sun. 2011-03-20 at 07:47 PM EDT, William A. Rowe Jr. 
 wr...@rowe-clan.net wrote:

 [1] Note particularly that expat appears to be abandoned, no releases
 in almost 4 yrs, with a significant security issue hanging over it we
 patched in apr.  No effort appears to be expended in providing any
 alternate non-expat apr_xml interfaces.

 For APR to continue bundling expat seems easiest, in the absence of
 anyone motivated to do something more.

 I wish we had a better understanding of where expat is headed, or if it
 is truly abandoned.  It seems strange to rely on an orphaned dependency.

 Anyone have any inside knowledge or informed opinion?

I'm a committer on Expat, but (as you've noted) the project has had no
attention for quite a while. I wasn't aware of a security problem in
there, however.

Even if I dropped a new release of Expat, would we want to rely on the
external build (and latest release being propagated) or continue to
ship a patched Expat within APR?

Switching to libxml2 would be possible (it is MIT licensed), but would
require a lot more coding work in the xml support. Users of APR (1.x)
also depend on Expat being available, and a switch would require them
to rewrite their XML parsing code. Maybe that is acceptable for apps
to switch to 2.0?

In short: I can make a release happen, but would that matter to the APR project?

Cheers,
-g

Re: where is dav_get_limit_xml_body?

[Greg Stein]

On Sun, Mar 20, 2011 at 14:59, Guenter Knauf fua...@apache.org wrote:
 Am 20.03.2011 19:41, schrieb William A. Rowe Jr.:

 Go ahead and simply remove it, just as the docs team would backport
 whatever
 documentation cleanup was appropriate without a STATUS dance.  No code is
 actually harmed in this exercise.

 done:
 http://svn.apache.org/viewvc?rev=1083536view=rev

Cool. Thanks for the (late) cleanup! :-P

Cheers,
-g

Re: Prior to apr 2.0 / httpd 2.4...

[Greg Stein]

On Mon, Mar 21, 2011 at 12:23, Guenter Knauf fua...@apache.org wrote:
 Greg,
 Am 21.03.2011 15:38, schrieb Greg Stein:
...
 I'm a committer on Expat, but (as you've noted) the project has had no
 attention for quite a while. I wasn't aware of a security problem in
 there, however.

 Even if I dropped a new release of Expat, would we want to rely on the
 external build (and latest release being propagated) or continue to
 ship a patched Expat within APR?

 Switching to libxml2 would be possible (it is MIT licensed), but would
 require a lot more coding work in the xml support. Users of APR (1.x)
 also depend on Expat being available, and a switch would require them
 to rewrite their XML parsing code. Maybe that is acceptable for apps
 to switch to 2.0?

 I followed up with libxml2 for a while on NetWare, and every now and then
 compilation was broken with next release due to not only fixing bugs but
 also adding a bunch of new features which then require futher tweaks (search
 for stubs which provide missing OS functions in network layer, etc).
 Further more many projects dont care about issues with compilers which dont
 like declarations after statements, and often you then end up with
 uncompilable code :-(

Yeah. In Subversion, we have a bunch of Windows developers, and they
call out when declarations occur after statements :-)

 In short: I can make a release happen, but would that matter to the APR
 project?

 when I tried to compile for Win32 with Watcom C I had to add this to expat:
 --- expat.h.orig        Mon Nov 27 03:51:58 2006
 +++ expat.h     Mon Aug 09 16:27:36 2010
 @@ -193,11 +193,19 @@
                       XML_XmlDeclHandler xmldecl);


 +#if defined(WIN32)  defined(__WATCOMC__)
 +typedef struct {
 +  void * __watcall (*malloc_fcn)(size_t size);
 +  void * __watcall (*realloc_fcn)(void *ptr, size_t size);
 +  void __watcall (*free_fcn)(void *ptr);
 +} XML_Memory_Handling_Suite;
 +#else
  typedef struct {
   void *(*malloc_fcn)(size_t size);
   void *(*realloc_fcn)(void *ptr, size_t size);
   void (*free_fcn)(void *ptr);
  } XML_Memory_Handling_Suite;
 +#endif

Seems reasonable. There have been a number of other little compilation
bug reports that have crept in over time. Could probably spend a day
just closing out those issues.

  /* Constructs a new parser; encoding is the encoding specified by the
    external protocol or NULL if there is none specified.

 BTW. is there a public repo from where oen can fetch current code?

http://sourceforge.net/scm/?type=cvsgroup_id=10127

 oh, and while on things to fix where you are commiter:
 another one who plays with httpd and subversion on NetWare told me that
 current code of libserf has its quirks on NetWare - are you willing to take
 a look into that before we go for httpd GA?

I don't see how httpd GA is related to serf?? ... certainly, you want
serf fixed up for a NetWare Subversion. But does httpd 2.4 consume
libserf nowadays? (ie. one of the proxy modules?)

 And where to post patches? To you directly?

serf-...@googlegroups.com

and/or open issues at code.google.com/p/serf/

Cheers,
-g

Fwd: Prior to apr 2.0 / httpd 2.4...

[Greg Stein]

I saw dev and was thinking this was on dev@apr... but it was @httpd.

Anyways... APR peeps: see below.


-- Forwarded message --
From: Greg Stein gst...@gmail.com
Date: Mon, Mar 21, 2011 at 10:38
Subject: Re: Prior to apr 2.0 / httpd 2.4...
To: dev@httpd.apache.org, William A. Rowe Jr. wr...@rowe-clan.net


On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 3/20/2011 7:43 PM, Dan Poirier wrote:
 On Sun. 2011-03-20 at 07:47 PM EDT, William A. Rowe Jr. 
 wr...@rowe-clan.net wrote:

 [1] Note particularly that expat appears to be abandoned, no releases
 in almost 4 yrs, with a significant security issue hanging over it we
 patched in apr.  No effort appears to be expended in providing any
 alternate non-expat apr_xml interfaces.

 For APR to continue bundling expat seems easiest, in the absence of
 anyone motivated to do something more.

 I wish we had a better understanding of where expat is headed, or if it
 is truly abandoned.  It seems strange to rely on an orphaned dependency.

 Anyone have any inside knowledge or informed opinion?

I'm a committer on Expat, but (as you've noted) the project has had no
attention for quite a while. I wasn't aware of a security problem in
there, however.

Even if I dropped a new release of Expat, would we want to rely on the
external build (and latest release being propagated) or continue to
ship a patched Expat within APR?

Switching to libxml2 would be possible (it is MIT licensed), but would
require a lot more coding work in the xml support. Users of APR (1.x)
also depend on Expat being available, and a switch would require them
to rewrite their XML parsing code. Maybe that is acceptable for apps
to switch to 2.0?

In short: I can make a release happen, but would that matter to the APR project?

Cheers,
-g

Re: On topic serf/NetWare

[Greg Stein]

Thanks, Norm! In the future, please send serf issues to
serf-...@googlegroups.com (cc'd).

We'll get this added before the next release.

Cheers,
-g

On Mon, Mar 21, 2011 at 19:10, NormW no...@gknw.net wrote:
 Hi all,
 In serf src .\buckets\mmap_buckets.c :

 it needs something like :

 @@ -16,6 +16,8 @@
  #include apr_pools.h
  #include apr_mmap.h

 +#if APR_HAS_MMAP
 +
  #include serf.h
  #include serf_bucket_util.h

 @@ -119,3 +121,6 @@
     serf_default_restore_snapshot,
     serf_default_is_snapshot_set,
  };
 +
 +#endif /* APR_HAS_MMAP */
 +

 as not all (ahem) OS support mmap, as suggested by APR define.

 Regards,
 Norm

Re: where is dav_get_limit_xml_body?

[Greg Stein]

The function name is probably obsolete. I'm away from my laptop, so can't
find the answer. Search the source for that Limit directive mentioned, and
work out from there. I think I moved it out of mod_dav into a more generic
location
On Mar 20, 2011 8:47 AM, Guenter Knauf fua...@apache.org wrote:
 I was just testing if I could automatically create an export list for
 mod_dav when I found this in mod_dav.h:

 /* 
 **
 ** MISCELLANEOUS STUFF
 */

 /* fetch the LimitXMLRequestBody in force for this resource */
 DAV_DECLARE(apr_size_t) dav_get_limit_xml_body(const request_rec *r);

 which source file should this function provide? I did search through the
 whole source tree, but couldnt find any other reference to this symbol ...
 (BTW. same is in 2.2.x branch too)

 Gün.

Re: Remove Limit and LimitExcept ?

[Greg Stein]

The Limit/LimitExcept directives are *very* handy and important when
mod_dav is being used. In fact, LimitExcept was created specifically
in order to avoid listing every new method that might come along via
DAV specs and such.

As long as an alternative is available, then I don't care. But the
functionality is very important.

Cheers,
-g

On Sat, Sep 18, 2010 at 18:45, Stefan Fritsch s...@sfritsch.de wrote:
 This is from https://issues.apache.org/bugzilla/show_bug.cgi?id=49927

 On Saturday 18 September 2010, bugzi...@apache.org wrote:
 --- Comment #3 from Nick Kew n...@webthing.com 2010-09-18
 06:38:34 EDT ---

  No, the current documentation is correct. The semantics of
  Limit/LimitExcept is just insane. We should relly get rid if it
  in 2.4 and improve the docs for 2.2. Maybe the unprotected
  should be big, red, and blinking ;-)

 Agreed.  We can even document it as superseded by
 If $request-method ...
 having of course checked the expression parser, which probably
 needs updating to support things like
    ... in GET,HEAD,OPTIONS,TRACE
 without some nasty great OR expression.

 What do other people think about removing Limit and LimitExcept
 and adding mod_allowmethods from the sandbox to easily forbid some
 methods? Or would this create too much trouble when upgrading
 configurations?


 BTW, we could also add an authz provider to allow things like

 Require method GET,HEAD,...

 Though this would be slower than mod_allowmethods because authz
 providers have to parse the require line on every request.

Re: subversion-1.6.12, apache-2.3.6

[Greg Stein]

[resending; the original has httpd.apache.COM ...]

On Mon, Jun 28, 2010 at 15:12, Greg Stein gst...@gmail.com wrote:
 On Mon, Jun 28, 2010 at 05:20, Philip Martin philip.mar...@wandisco.com 
 wrote:
 Bert Huijben b...@qqmail.nl writes:

 -Original Message-
 From: szukw...@arcor.de [mailto:szukw...@arcor.de]
 Sent: maandag 28 juni 2010 9:51
 To: d...@subversion.apache.org
 Subject: Re: subversion-1.6.12, apache-2.3.6

 I know that httpd-2.3.x is alpha. Second trial for the patch.

 Thanks for your patch, it came through this time.
 To apply the patch to trunk we need code that works on older and newer
 versions of httpd (E.g. including proper checking for which version is being
 used).

  I assume you know more about how we should check for specific httpd
 versions than we do as you are testing httpd alpha's.

 I think there is an apache bug here.  This is the revision that
 changed the dav_new_error API (in mod_dav.h):

 http://svn.apache.org/viewvc?view=revisionrevision=882274

 It includes a change to ap_mmn.h, but that change only modifies the
 comments, it doesn't change MODULE_MAGIC_NUMBER_MAJOR. Thus callers
 cannot determine which version of the API to use.

 Yup... along with making other changes to keep up with further MMN
 bumps since then. (eg. the AP_LOG_MARK change that OP mentioned)

 Cheers,
 -g

Re: Fast by default

[Greg Stein]

Geez, Eric. No wonder people don't want to contribute to httpd, when they
run into an attitude like yours. That dismissiveness makes me embarressed
for our community.

There is zero reason for us to avoid putting deflate into the default
configuration.

It is also very arguable that we should leave it off. I think others have
argued well to enable it by default, while you've simply dismissed them with
your holier-than-thou attitude and lack of any solid rationale.

-g

On May 31, 2010 8:06 PM, Eric Covener cove...@gmail.com wrote:

On Mon, May 31, 2010 at 8:30 PM, Bryan McQuade bmcqu...@google.com wrote:
 I propose providing an...
An additional httpd.conf doesn't sound valuable to me.  What slice of
non-savvy users would scrutinize an alternate config file, can replace
the config file of their webserver, isn't using a webserver packaged
by their OS, and wouldn't have just gotten the same information today
from the manual and 400,000 other websites?

There's currently no ifModule bloat in the default conf, but you're
welcome to submit a patch that adds one for deflate or expires (latter
seems more unwise to me). See the supplemental configuration section
of the generated config.

This doesn't address mass-vhost companies failing to allow deflate
because it's not in the no-args HTTPD ./configure , which sounds
far-fetched to me.  I can't recall a users@ or #httpd user implying
being subjected to such a thing with their own build or with cheap
hosting.

--

Eric Covener
cove...@gmail.com

Re: ACL changes in mod_dav

[Greg Stein]

This is pretty cool. I'm assuming you're referring to the WebDAV ACL
spec features?

Every time that I started to look into the issue, I ran into one basic
issue: how to notify the multiple processes that the ACLs around a
particular namespace have changed. How did you handle that?

Cheers,
-g

On Sat, Feb 20, 2010 at 23:23,  markus.l...@dlr.de wrote:
 Hi,

 I have added ACL features to the mod_dav module. Could you tell me the
 correct way to get this changes reviewed and into to official
 mod_dav-source?

 Thanks,
 Markus

Re: Httpd 3.0 or something else

[Greg Stein]

On Fri, Nov 13, 2009 at 14:01, Arturo 'Buanzo' Busleiman
bua...@buanzo.com.ar wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Matthieu Estrade wrote:
 What about the non http protocol like ftp, or smtp tested during summer
 code ? The tentation to have a powerful core that we could adapt to any
 protocol we want...

 And Google just released SPDY (Speedy), a non-http protocol for web 
 transport...

Paul and I briefly discussed adding some stuff to serf that could
allow serf to do SPDY. For example, add the notion of priority into
the request system. It would be ignored in a normal connection, but
could then take effect in a SPDY connection.

Cheers,
-g