Study about developer and commits.

[mario-fa]

We are studying behavior and characteristic about Open Source Software (OSS)
development using by reference “What can OSS mailing lists tell us? A
preliminary psychometric text analysis of the Apache developer mailing list
(Hassan , Rigby)” that used the Apache httpd server developer mailing list. 
We need to know are major developer commit in the Project Apache HTTP Server
(4 developers) for to continue our study. Do you help us? Where do We can
find this information?
Thanks you for your attention.

Mário André
Master’s degree student 
-- 
View this message in context: 
http://old.nabble.com/Study-about-developer-and-commits.-tp26523052p26523052.html
Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.

Re: [VOTE] Release httpd 2.3.4-alpha

[Paul Querna]

On Wed, Nov 25, 2009 at 2:43 PM, Paul Querna  wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
>   
>
> Your votes please;
>
>  +/- 1
>  [  ]  Release httpd-2.3.4 as Alpha
>
> Vote closes at 18:00 UTC on Monday November 30 2009.
>
> May your Thanksgiving be filled with Turkey and httpd testing,

Problems encountered when installing on aurora.apache.org (Solaris 10/SPARC):
 - Had to modify configure scripts to use /bin/bash instead of /bin/sh (ideas?)
 - Had to `ln -s apr_dbm_db.so apr_dbm_db-1.so`, otherwise all DBM
functions fail.

Otherwise it seems to be running fine as www.apache.org w/ the Event MPM.

[VOTE] Release httpd 2.3.4-alpha

[Paul Querna]

Test tarballs for Apache httpd 2.3.4-alpha are available at:
   

Your votes please;

 +/- 1
 [  ]  Release httpd-2.3.4 as Alpha

Vote closes at 18:00 UTC on Monday November 30 2009.

May your Thanksgiving be filled with Turkey and httpd testing,

Thanks,

Paul

Re: a directive to select the pollset implementation?

[Jeff Trawick]

On Wed, Nov 25, 2009 at 10:42 AM, Niklas Edmundsson  wrote:
> On Tue, 24 Nov 2009, Jeff Trawick wrote:
>
>> As with mutex implementations, APR pollset implementations, or the
>> underlying OS support, are occasionally broken for some
>> configurations; the access to multiple implementations in APR 1.4.x
>> lends itself to allowing the user to specify a non-default pollset
>> implementation.
>>
>> For example, the following could be used to work around the temporary
>> epoll sysdef confusion on Linux, or (cough) the port_getn() interface
>> challenges on Solaris:
>
> Why am I feeling that figuring out which implementation of what works or not
> should be done automagically, either by configure or at startup?

We'd agree with you on figuring out implementations at configure time,
either by probing the system or by explicit decisions based on
experience.

I can't think of any startup-time decisions that would be practical;
did you think of any in particular?

> Enabling all these user-choices might backfire with "Oh, you're running foo
> on bar. But of course you know that you should fiddle with the thingamajig,
> because we were too lazy to do a configure test".

Who is that a problem for, ignoring for a moment the notion that we've
been offering mutex mechanism selection, albeit incomplete and
inconsistent, for a number of years now because we were too lazy to do
a configure test?

>
> I'm not being averse to tunability when it comes to selecting
> implementations that performs better given somewhat equal functionality, but
> when it's works-or-not I'd rather have the dysfunctional alternatives weeded
> out and never exposed to the end user...

Generally:

1. we (mostly while wearing our APR hats) do try to figure out
appropriate implementations at build time so that no such
configuration is required; in turn, we expect that most users don't
need to configure mutexes or pollsets
2. some underlying mechanisms have unavoidable technical trade-offs
that need to be put in the hands of the administrator if optimal
performance is to be achieved
3. a lot of use cases for controlling the mutex mechanism or
potentially the pollset are not seen first by developers; users have
some pre-built apr/httpd in hand, encounter some unforeseen issue, and
want to make it work; this can be especially painful for users who
don't/can't build from source, such that it takes a while for a fix to
a particular implementation bug or a new default choice to be widely
distributed; in the meantime, configurability is a great help

Something that works against absolute minimization of user problems is
the moderately aggressive use of new system features when found at
configure time, which may be required for advanced application use
(e.g., Event MPM) but not necessary for casual users.  Sometimes these
newer features are more volatile in the early years.  As most httpd
and/or apr users get their code from a vendor, those vendors can
easily select less risky (but sometimes lower performing or
functionally reduced) mechanisms as their default.

Re: a directive to select the pollset implementation?

[Niklas Edmundsson]

On Tue, 24 Nov 2009, Jeff Trawick wrote:


As with mutex implementations, APR pollset implementations, or the
underlying OS support, are occasionally broken for some
configurations; the access to multiple implementations in APR 1.4.x
lends itself to allowing the user to specify a non-default pollset
implementation.

For example, the following could be used to work around the temporary
epoll sysdef confusion on Linux, or (cough) the port_getn() interface
challenges on Solaris:


Why am I feeling that figuring out which implementation of what works 
or not should be done automagically, either by configure or at 
startup?


Enabling all these user-choices might backfire with "Oh, you're 
running foo on bar. But of course you know that you should fiddle with 
the thingamajig, because we were too lazy to do a configure test".


I'm not being averse to tunability when it comes to selecting 
implementations that performs better given somewhat equal 
functionality, but when it's works-or-not I'd rather have the 
dysfunctional alternatives weeded out and never exposed to the end 
user...



/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se  | ni...@acc.umu.se
---
 Raise electric eels-gain a lot of current popularity
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

RE: back port off patch CVE-2009-3555-2.2.patch for 2.0.x

[Plüm, Rüdiger, VF-Group]

 

> -Original Message-
> From: Hartmut Keil 
> Sent: Mittwoch, 25. November 2009 13:51
> To: dev@httpd.apache.org
> Subject: back port off patch CVE-2009-3555-2.2.patch for 2.0.x
> 
> Hi
> 
> are there plans for backporting the patch 
> http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2
> 009-3555-2.2.patch
> for 2.0.63 ? Is a backport desired?

See

http://svn.apache.org/viewvc?view=revision&revision=882861
http://people.apache.org/~rjung/patches/cve-2009-3555_httpd_2_0_x-v2.patch
 
Regards

Rüdiger

back port off patch CVE-2009-3555-2.2.patch for 2.0.x

[Hartmut Keil]

Hi

are there plans for backporting the patch 
http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch
for 2.0.63 ? Is a backport desired?

Regards
Hartmut

Re: [mod_fcgid] Feedback / Suggestions

[Olaf van der Spek]

On Wed, Nov 25, 2009 at 12:54 PM, Edgar Frank  wrote:
> 2009/11/25 Olaf van der Spek 
>> > Yes, you're right. In a FCGI_GET_VALUES request, the backend can send
>> > arbitrary name-value-pairs. Unfortunately there is no standard way to tell
>> > the frontend that this feature is supported. Maybe, making the name (and
>> > expected value) of this name-value-pair configurable in mod_fcgid could
>> > be a reasonable way.
>>
>> Doesn't sound reasonable either. If you introduce such a feature, it
>> should simply be coordinated with other FastCGI stakeholders.
>
> You're right, again. I'm just wondering if such a change is likely to happen.
> Last update was 2002. I'd like to propose a change to the FastCGI
> stakeholders, if this makes any sense from a single, unrelated person.

The official spec is unlikely to change, so you'd have to coordinate
with other web server and backend developers.

Olaf

Re: [mod_fcgid] Feedback / Suggestions

[Edgar Frank]

2009/11/25 Olaf van der Spek 
> > Yes, you're right. In a FCGI_GET_VALUES request, the backend can send
> > arbitrary name-value-pairs. Unfortunately there is no standard way to tell
> > the frontend that this feature is supported. Maybe, making the name (and
> > expected value) of this name-value-pair configurable in mod_fcgid could
> > be a reasonable way.
> 
> Doesn't sound reasonable either. If you introduce such a feature, it
> should simply be coordinated with other FastCGI stakeholders.

You're right, again. I'm just wondering if such a change is likely to happen.
Last update was 2002. I'd like to propose a change to the FastCGI
stakeholders, if this makes any sense from a single, unrelated person.

Edgar

Re: [mod_fcgid] Feedback / Suggestions

[Jeff Trawick]

On Tue, Nov 24, 2009 at 11:08 AM, Olaf van der Spek
 wrote:
> On Tue, Nov 24, 2009 at 5:03 PM, Jeff Trawick  wrote:
>>> What advantages does fcgid have over proxy_fcgi (except being ready)?
>>
>> integrated, on-demand process management
>
> How valuable is that?
> In most cases a static number of backends seems fine.

compared with mod_proxy_fcgi, the little or no required
configuration/management of application processes with mod_fcgid makes
it easier for newbies and/or casual users; at the same time it is
sufficient for most sites, though perhaps with a little more config
tweaking to allow higher spawn rates or larger pools per application

>
>>> mod_fcgid isn't in 2.2, right?
>>
>> mod_fcgid is actually not bundled with the HTTP server.  It is
>> released on its own cycle, and supports httpd 2.0.x, 2.2.x, and trunk
>> (future httpd 2.4.x) with one delivery.
>
> Ah, nice. What's the reason it's not bundled though?

I expect to see relatively high activity (compared with any particular
bundled module) in mod_fcgid over the next 6 months or so.  Given
that,

* bundling means considerable extra work to get fixes into both httpd
trunk and the separate mod_fcgid tree that would continue to support
httpd 2.0.x/2.2.x; that gets worse when httpd 2.4 is GA, as a fix
could apply to httpd trunk, httpd 2.4.x branch, and the separate
mod_fcgid tree
* releasing of mod_fcgid fixes would be held up by the httpd release cycle

>
> In this case, I'd love to see support for TCP/IP backends too.
> Shouldn't be too hard to implement.
>
>>> So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi
>>> expected to be not ready for 2.4?
>>
>> mod_fcgid will support 2.4.  proxy-fcgi folk(s), care to speak up on your 
>> baby?
>
> Olaf
>

Re: [mod_fcgid] Feedback / Suggestions

[Olaf van der Spek]

On Wed, Nov 25, 2009 at 12:17 PM, Edgar Frank  wrote:
>> Wouldn't it be better to have the backend tell the frontend that it
>> supports this feature? Manual configuration should be avoided if
>> possible.
>
> Yes, you're right. In a FCGI_GET_VALUES request, the backend can send
> arbitrary name-value-pairs. Unfortunately there is no standard way to tell the
> frontend that this feature is supported. Maybe, making the name (and expected
> value) of this name-value-pair configurable in mod_fcgid could be a reasonable
> way.

Doesn't sound reasonable either. If you introduce such a feature, it
should simply be coordinated with other FastCGI stakeholders.

Olaf

Re: [mod_fcgid] Feedback / Suggestions

[Edgar Frank]

2009/11/26 Olaf van der Spek 
> On Wed, Nov 25, 2009 at 11:37 AM, Edgar Frank  wrote:
> > Maybe, in implementing this in mod_fcgid and making it configurable,
> > Apache can serve more intelligent backends better.
> 
> Wouldn't it be better to have the backend tell the frontend that it
> supports this feature? Manual configuration should be avoided if
> possible.

Yes, you're right. In a FCGI_GET_VALUES request, the backend can send
arbitrary name-value-pairs. Unfortunately there is no standard way to tell the
frontend that this feature is supported. Maybe, making the name (and expected
value) of this name-value-pair configurable in mod_fcgid could be a reasonable
way.

Edgar

Re: [mod_fcgid] Feedback / Suggestions

[Olaf van der Spek]

On Wed, Nov 25, 2009 at 11:37 AM, Edgar Frank  wrote:
> Maybe, in implementing this in mod_fcgid and making it configurable, Apache
> can serve more intelligent backends better.

Wouldn't it be better to have the backend tell the frontend that it
supports this feature? Manual configuration should be avoided if
possible.

Olaf

Re: [mod_fcgid] Feedback / Suggestions

[Edgar Frank]

2009/11/25 Graham Dumpleton 
> 2009/11/25 Edgar Frank :
> > While delving into the FCGI and CGI spec, I encountered another reason not
> > to stream client data directly. CGI wants an explicitly set CONTENT_LENGTH
> > and FCGI enforces than rather obsoletes this (last sentence in 6.2 of the
> > FCGI spec).
> > If the client sends for any reason a message body with no CONTENT_LENGTH
> > set or CONTENT_LENGTH to be ignored as defined by RFC2616, you have to
> > read the full message body to determine the correct content length
> > which should be transferred to the backend.
> 
> Things can get worse. Even if CONTENT_LENGTH is sent, if you have
> requests with compressed content which is decompressed by mod_deflate,
> the amount of content will not actually match what CONTENT_LENGTH says
> there will be as it reflects how things are before content is
> decompressed.

I implied this by originally meaning "read the full message body
through all input filters". Thanks for pointing this out.

> Don't know about FASTCGI in general, but for WSGI (Python higher level
> interface that can sit on CGI or FASTCGI) they have the stupid
> requirement that you take CONTENT_LENGTH as being precise and that you
> must not read more than CONTENT_LENGTH. If CONTENT_LENGTH isn't
> provided, WSGI says you are supposed to take it as meaning no data.
> 
> [...]
>
> Anyway, don't know if this is at all relevant to FASTCGI. As you point
> out though, the CONTENT_LENGTH requirement does at least prevent
> FASTCGI from handling chunked request content. WSGI specification has
> same stupid limitation.

At least if you adhere strictly to the spec, you have to do it this way for
FastCGI, too. Although FastCGI provides the means to explicitly tell the
backend when the end-of-stream is hit.
I can't say if this is relevant in the real world, as there is still a chance
of more intelligent backends. I'll try it with PHP as soon as I find time for
this.

Maybe, in implementing this in mod_fcgid and making it configurable, Apache
can serve more intelligent backends better.

Regards,
Edgar

Re: [mod_fcgid] Feedback / Suggestions

[Graham Dumpleton]

2009/11/25 Edgar Frank :
>> On Tue, Nov 24, 2009 at 05:07 PM, Jeff Trawick  wrote:
>> >>> Or otherwise, can someone explain the details to me why it is as it is?
>> >>> Especially in terms of not pipeling data directly (maybe after a little
>> >>> buffering to build proper FCGI packets)? The comment in
>> >>> fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this
>> >>> keep the server in processing too long? Processing takes its time either
>> >>> way, I'd assume. Looking forward to enlightment. :)
>> >>
>> >> I can only guess that the problem at hand when this was implemented
>> >> was that some backend application processes were so expensive that
>> >> that they couldn't be tied up until all data had been read from slow
>> >> clients.
>> >>
>> > Yes, Jeff is right :)
>>
>> This is a reasonable feature; once streaming to the app is implemented
>> this alternate mechanism can be enabled with a per-request envvar
>> (e.g., SetEnv in the directory or location).
>
> Thanks for explaining this to me.
>
> While delving into the FCGI and CGI spec, I encountered another reason not to
> stream client data directly. CGI wants an explicitly set CONTENT_LENGTH and
> FCGI enforces than rather obsoletes this (last sentence in 6.2 of the FCGI
> spec).
> If the client sends for any reason a message body with no CONTENT_LENGTH set
> or CONTENT_LENGTH to be ignored as defined by RFC2616, you have to read the
> full message body to determine the correct content length which should be
> transferred to the backend.

Things can get worse. Even if CONTENT_LENGTH is sent, if you have
requests with compressed content which is decompressed by mod_deflate,
the amount of content will not actually match what CONTENT_LENGTH says
there will be as it reflects how things are before content is
decompressed.

Don't know about FASTCGI in general, but for WSGI (Python higher level
interface that can sit on CGI or FASTCGI) they have the stupid
requirement that you take CONTENT_LENGTH as being precise and that you
must not read more than CONTENT_LENGTH. If CONTENT_LENGTH isn't
provided, WSGI says you are supposed to take it as meaning no data.

For WSGI at least, means you can't have mutating input filters unless
the input filter buffers up all the request content after doing what
it does and recalculates CONTENT_LENGTH and sends through modified
value. In practice input filters don't do this.

Anyway, don't know if this is at all relevant to FASTCGI. As you point
out though, the CONTENT_LENGTH requirement does at least prevent
FASTCGI from handling chunked request content. WSGI specification has
same stupid limitation.

If things were defined so as to simply read until all input exhausted
and for CONTENT_LENGTH really only to be used as a hint or in
determining if original request body may be too large, wouldn't be
such a pain.

Graham

Re: [mod_fcgid] Feedback / Suggestions

[Edgar Frank]

> On Tue, Nov 24, 2009 at 05:07 PM, Jeff Trawick  wrote:
> >>> Or otherwise, can someone explain the details to me why it is as it is?
> >>> Especially in terms of not pipeling data directly (maybe after a little
> >>> buffering to build proper FCGI packets)? The comment in
> >>> fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this
> >>> keep the server in processing too long? Processing takes its time either
> >>> way, I'd assume. Looking forward to enlightment. :)
> >>
> >> I can only guess that the problem at hand when this was implemented
> >> was that some backend application processes were so expensive that
> >> that they couldn't be tied up until all data had been read from slow
> >> clients.
> >>
> > Yes, Jeff is right :)
> 
> This is a reasonable feature; once streaming to the app is implemented
> this alternate mechanism can be enabled with a per-request envvar
> (e.g., SetEnv in the directory or location).

Thanks for explaining this to me.

While delving into the FCGI and CGI spec, I encountered another reason not to
stream client data directly. CGI wants an explicitly set CONTENT_LENGTH and
FCGI enforces than rather obsoletes this (last sentence in 6.2 of the FCGI
spec).
If the client sends for any reason a message body with no CONTENT_LENGTH set
or CONTENT_LENGTH to be ignored as defined by RFC2616, you have to read the
full message body to determine the correct content length which should be
transferred to the backend.

Regards,
Edgar