<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.apache.devel">
    <title>gmane.comp.apache.devel</title>
    <link>http://blog.gmane.org/gmane.comp.apache.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48358"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48357"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48354"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48346"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48341"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48338"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48331"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48330"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48327"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48315"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48304"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48299"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48285"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48284"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48278"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48271"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48262"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48258"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48257"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.apache.devel/48256"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48358">
    <title>range request support using ap_send_fd</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48358</link>
    <description>&lt;pre&gt;Hi,

I'm working on a problem where mod_perl doesn't seem to accept range
requests documented here:

    http://www.gossamer-threads.com/lists/modperl/dev/104360

Working with 2.2.22, my issue seems to be the mod_perl sendfile
implementation uess ap_send_fd, and ap_send_fd does not create an EOS
bucket, so in byterange_filter.c:

/*
* Don't attempt to do byte range work if this brigade doesn't
* contain an EOS, or if any of the buckets has an unknown length;
* this avoids the cases where it is expensive to perform
* byteranging (i.e. may require arbitrary amounts of memory).
*/

if (!APR_BUCKET_IS_EOS(e) || clength &amp;lt;= 0) {
ap_remove_output_filter(f);
return ap_pass_brigade(f-&amp;gt;next, bb);
} 

we don't handle range requests, and so my mod_perl handler does not work
with range requests.

My question is should ap_send_fd be inserting an eos bucket? i.e.

alex&amp;lt; at &amp;gt;alex ~/httpd-2.2.22 $ diff -u server/protocol.c.orig server/protocol.c
--- server/protocol.c.orig2012-01-24 12:02:19.000000000 -0800
+++ server/protocol.c&lt;/pre&gt;</description>
    <dc:creator>Alex Krohn</dc:creator>
    <dc:date>2012-05-25T01:29:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48357">
    <title>post-CVE-2011-4317 (rewrite proxy unintended interpolation) rewrite PR's</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48357</link>
    <description>&lt;pre&gt;There are a couple of PR's going around about people who were using
rewrite to operate on URL's now kicked out of mod_rewrite by default
(IIRC at least proxy:blah and CONNECT arg)

Should we just add a mod_rewrite directive or RewriteOption that opts
in to handling any URL and document the cautions in the directive?  I
don't mind doing that code and doc work to skip the new check to
unblock people before 2.2.23.  Please comment!

&lt;/pre&gt;</description>
    <dc:creator>Eric Covener</dc:creator>
    <dc:date>2012-05-24T15:12:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48354">
    <title>Please unsubscribe me &lt;eom&gt;</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48354</link>
    <description>&lt;pre&gt;
&lt;/pre&gt;</description>
    <dc:creator>Harish S Rathod</dc:creator>
    <dc:date>2012-05-24T08:47:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48346">
    <title>CLOSE_WAIT problem</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48346</link>
    <description>&lt;pre&gt;Hi all,

When I tested mod_proxy + mod_proxy_balancer + (mod_proxy_ajp or
mod_proxy_http) with worker mpm, I always met CLOSE_WAIT state in apache
proxy side.

I tested the following scenario.

- Sending a request at the browser -&amp;gt; apache,  mod proxy -&amp;gt; ajp or http java
server(1)
- Normally, browser received the response correctly and the connection state
was ESTABLISHED.
- And java server closed the ajp or http connection with timeout(Or
terminate java server forcibly).
- Then apache proxy machine always had the CLOSE_WAIT state about the
connection.

It seemed that the apache proxy modules did not try to close the invalid
socket which had been already closed at the peer side(the backend java
server side).

Perhaps is it already the known issue?

Please give me some advice if I am misunderstanding something.

Thanks!

--
apache version: 2.4.2
backend java server: grizzly http/ajp, playframework(maybe it uses netty)
os: Apache(Linux 2.6.18 x86_64), BackendServer(MacOs)
--

Regards,
Bongjae Chang


&lt;/pre&gt;</description>
    <dc:creator>Bongjae Chang</dc:creator>
    <dc:date>2012-05-23T05:35:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48341">
    <title>Comment system, take two</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48341</link>
    <description>&lt;pre&gt;In light of recent concerns about the Disqus system, I've taken it upon
myself to figure out an alternative we can use for adding comments to
our pages. And so, through the better half of a day, I worked on
creating a new system that is without any evil tracking mechanisms of
any sort except for what people themselves will allow - that is, only
information that is willingly entered will be stored, no IPs or such.

The result (thus far) can be seen at a small test page I made for the
http project at http://c.apaste.info/httpd.html - feel free to give it a
test spin and see what you like.

Quick primer:

Click on "add a comment" to add a comment, or click on "reply" to add a
reply to an existing comment. You can use the "log in" link to the far
right to create a permanent account which will save you the trouble of
having to type your name/email whenever you want to make a new comment.

People that register an account can also be added as moderators/admins,
and thus delete posts as they see fit. Furthermore, mo&lt;/pre&gt;</description>
    <dc:creator>Daniel Gruno</dc:creator>
    <dc:date>2012-05-21T21:04:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48338">
    <title>Bug report for Apache httpd-2 [2012/05/20]</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48338</link>
    <description>&lt;pre&gt;+---------------------------------------------------------------------------+
| Bugzilla Bug ID                                                           |
|     +---------------------------------------------------------------------+
|     | Status: UNC=Unconfirmed NEW=New         ASS=Assigned                |
|     |         OPN=Reopened    VER=Verified    (Skipped Closed/Resolved)   |
|     |   +-----------------------------------------------------------------+
|     |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
|     |   |           MIN=Minor   NOR=Normal    ENH=Enhancement TRV=Trivial |
|     |   |   +-------------------------------------------------------------+
|     |   |   | Date Posted                                                 |
|     |   |   |          +--------------------------------------------------+
|     |   |   |          | Description                                      |
|     |   |   |          |                                                  |
| 7483|As&lt;/pre&gt;</description>
    <dc:creator>bugzilla&lt; at &gt;apache.org</dc:creator>
    <dc:date>2012-05-20T07:15:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48331">
    <title>Status of bugs in the Documentation project</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48331</link>
    <description>&lt;pre&gt;Hi,

I posted a patch to the docs under Bug 53201 last week and was hoping
for some feedback. Looking at the other bugs in that project, it
doesn't look like they are being assigned (10 bugs are listed in there
and are still new).

I also don't see those bugs posted in the bugs&amp;lt; at &amp;gt;httpd.apache.org. Are
they getting lost in the bit bucket?

Thanks,
Walter Goulet

&lt;/pre&gt;</description>
    <dc:creator>Walter Goulet</dc:creator>
    <dc:date>2012-05-16T03:24:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48330">
    <title>SuexecUserGroup inside Directory context</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48330</link>
    <description>&lt;pre&gt;Is there any security (or technical) reason for not allowing
SuexecUserGroup to be defined inside &amp;lt;Directory&amp;gt; context?
Judging by the code -- it should be trivial to implement, but I wanted to
check if there are any pitfalls/reasons for not doing so.

The use case where it is needed:
Shared hosting, each virtual hosts runs as a particular user.
Yet, there are single installation of roundcube, phpmysql, etc, per server.
Access to is defined via Alias, like this:

Alias /phpmyadmin "/var/www/html/phpMyAdmin/"****

Alias /squirrelmail "/var/www/html/squirrelmail/"****

Alias /roundcube "/var/www/html/roundcube/"


That way customer can access webapp using:
http://customerdomain.com/roundcube
The applications runs as user (due to SuexecUserGroup in VirtualHost for
the customer). So, php files for that application has to be readable by
that user.
Yet, they might contain some sensitive information that end user shouldn't
know - like mysql login/password.

If we could define something like:
&amp;lt;Directory /var/www/html&lt;/pre&gt;</description>
    <dc:creator>Igor Seletskiy</dc:creator>
    <dc:date>2012-05-15T23:03:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48327">
    <title>Bug report for Apache httpd-2 [2012/05/13]</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48327</link>
    <description>&lt;pre&gt;+---------------------------------------------------------------------------+
| Bugzilla Bug ID                                                           |
|     +---------------------------------------------------------------------+
|     | Status: UNC=Unconfirmed NEW=New         ASS=Assigned                |
|     |         OPN=Reopened    VER=Verified    (Skipped Closed/Resolved)   |
|     |   +-----------------------------------------------------------------+
|     |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
|     |   |           MIN=Minor   NOR=Normal    ENH=Enhancement TRV=Trivial |
|     |   |   +-------------------------------------------------------------+
|     |   |   | Date Posted                                                 |
|     |   |   |          +--------------------------------------------------+
|     |   |   |          | Description                                      |
|     |   |   |          |                                                  |
| 7483|As&lt;/pre&gt;</description>
    <dc:creator>bugzilla&lt; at &gt;apache.org</dc:creator>
    <dc:date>2012-05-13T07:15:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48315">
    <title>Server Status Client IP</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48315</link>
    <description>&lt;pre&gt;Running a reverse proxy in front of Apache 2.4.2 (known reason, to get more reliable networking in Windows).

The proxy supplies  the X-Forwarded-For header and using in Apache:
LoadModule remoteip_module modules/mod_remoteip.so
RemoteIPHeader X-Forwarded-For 

The mod-status page gives as client IP,  the reverse proxy IP.
The access log gives the good client/remote IP.

Is this by design ?

Steffen&lt;/pre&gt;</description>
    <dc:creator>Steffen</dc:creator>
    <dc:date>2012-05-10T18:13:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48304">
    <title>c conf 2012</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48304</link>
    <description>&lt;pre&gt;Heya,

A friend of mine is helping organizing the first "C Conf":

  http://www.cconf.org/

I think it could be a very interesting conference for those of us that
still enjoy coding C :-)

I think it would be great if we could get a few talks submitted about
APR and HTTPD too, two projects with a long C history.  I personally
plan on being there if anyone wants to meet up then....

-Paul

&lt;/pre&gt;</description>
    <dc:creator>Paul Querna</dc:creator>
    <dc:date>2012-05-09T05:26:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48299">
    <title>[VOTE] CMS site migration</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48299</link>
    <description>&lt;pre&gt;Please cast your vote accordingly:

[ ] : +1 to migrate httpd-site to the CMS
[ ] :  0 don't care one way or the other
[ ] : -1 leave httpd-site as-is, because...

Note: this vote is only for httpd-site, not
any of the externals (eg the docs trees) that are pulled in.

T-72 hours before the results are tallied.
Voting rules are majority-consensus, same
as for releases.

&lt;/pre&gt;</description>
    <dc:creator>Joe Schaefer</dc:creator>
    <dc:date>2012-05-08T19:14:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48285">
    <title>split off or mark docu commits</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48285</link>
    <description>&lt;pre&gt;I'm really happy that our docu receives such great attention recently 
and is going to become much better as it seems ...

but due to the huge amount of commit messages I am no longer able to 
review *code* commit messages quickly when I have to pick 3 code commits 
out of 300 docu commits.
I would really like that we either split off the commit messages into a 
separate docu-commit list, or at least mark them with an additional
X-Committype:  docu
or something like that so that its possible to easily filter them.

Gün.



&lt;/pre&gt;</description>
    <dc:creator>Guenter Knauf</dc:creator>
    <dc:date>2012-05-07T10:18:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48284">
    <title>[DISCUSS] CMS site migration</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48284</link>
    <description>&lt;pre&gt;Over on docs&amp;lt; at &amp;gt; one of the recent conversations was
around moving the site documentation to the CMS,
starting first with the httpd site as a testbed.
After several hours of hacking on the site that
has now been accomplished, so we'd please like everyone
to review and comment on the httpd staging site now
available at 

    http://httpd.staging.apache.org/

which is perfectly compatible with the CMS's bookmarklet.
There are a few remaining syntax/style issues that need
addressing, but otherwise the content has been successfully
migrated from xdoc to markdown.

The sooner we can push this work into production the
less hassle it will be to keep the xdoc and content
trees in sync using two separate build systems.

After a few days have passed if there are no outstanding
issues remaining I plan to ask for a VOTE to finish the
migration of httpd-site to the CMS.  Thanks in advance
for your consideration!


&lt;/pre&gt;</description>
    <dc:creator>Joe Schaefer</dc:creator>
    <dc:date>2012-05-06T21:39:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48278">
    <title>Bug report for Apache httpd-2 [2012/05/06]</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48278</link>
    <description>&lt;pre&gt;+---------------------------------------------------------------------------+
| Bugzilla Bug ID                                                           |
|     +---------------------------------------------------------------------+
|     | Status: UNC=Unconfirmed NEW=New         ASS=Assigned                |
|     |         OPN=Reopened    VER=Verified    (Skipped Closed/Resolved)   |
|     |   +-----------------------------------------------------------------+
|     |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
|     |   |           MIN=Minor   NOR=Normal    ENH=Enhancement TRV=Trivial |
|     |   |   +-------------------------------------------------------------+
|     |   |   | Date Posted                                                 |
|     |   |   |          +--------------------------------------------------+
|     |   |   |          | Description                                      |
|     |   |   |          |                                                  |
| 7483|As&lt;/pre&gt;</description>
    <dc:creator>bugzilla&lt; at &gt;apache.org</dc:creator>
    <dc:date>2012-05-06T07:15:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48271">
    <title>Adding unit tests to httpd?</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48271</link>
    <description>&lt;pre&gt;Hi,

there are some parts of httpd where unit tests would allow easier 
testing or more complete test coverage than tests written for the perl 
framework. Examples include the ap_pcfg_* functions, the varbuf API, 
the regex plus API, and new interfaces that are not yet used by any 
module.

Therefore, I am thinking about adding unit tests to httpd. For maximum 
usefulness, such unit tests should be able to access functions that 
are not exported (including static functions). I could think of a few 
ways to achive this:

1) Add some preprocessor magic that exports the required functions 
when compiled with a special configure option. Then, put the unit 
tests into a separate module that executes them during server startup 
(and exits instead of allowing the startup to continue).

2) Put the unit tests into a separate executable using source files 
that #include the .c file(s) that contains the tested functions. This 
is a very hackish approach and has problems with source file 
interdependencies. It would lik&lt;/pre&gt;</description>
    <dc:creator>Stefan Fritsch</dc:creator>
    <dc:date>2012-05-04T21:27:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48262">
    <title>using X-Forwarded-Host as r-&gt;hostname</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48262</link>
    <description>&lt;pre&gt;Hi --

   It's been a remarkably long time since I had anything useful
to commit, and I'm pretty rusty, so I thought I'd throw this out for
discussion as a RTC despite the CTR rules on trunk.  I promise I won't
be offended if anyone says it's a stupid hack and should never be
committed, because, well, it is arguably a very stupid hack.

   I've been fighting a context where I have a new server behind
an ancient internal proxy for some transitional period of time until
we can replace the proxy too.  The proxy won't send Host headers (in
httpd terms, no equivalent to ProxyPreserveHost On functionality), but
it does put the originally requested Host header into X-Forwarded-Host.

   On the backend, try as I might, I could not find a way to map
the X-Forwarded-Host header on top of the Host one prior to the point
where the appropriate &amp;lt;VirtualHost&amp;gt; is determined.  I hoped for
some combo of mod_headers in "early" mode + mod_setenvif, but they
run in post_read_request in the opposite order from what I needed.

   &lt;/pre&gt;</description>
    <dc:creator>Chris Darroch</dc:creator>
    <dc:date>2012-05-03T22:57:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48258">
    <title>Status of Windows-work for 2.4.x</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48258</link>
    <description>&lt;pre&gt;I'm curious what the status of 2.4.x-on-Windows is... What else
can we do to speed this along?

&lt;/pre&gt;</description>
    <dc:creator>Jim Jagielski</dc:creator>
    <dc:date>2012-05-03T13:47:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48257">
    <title>Backport NPN patch?</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48257</link>
    <description>&lt;pre&gt;Would anyone object to the NPN patch (r1332643) being backported to 2.2 and 2.4?

&lt;/pre&gt;</description>
    <dc:creator>Ben Laurie</dc:creator>
    <dc:date>2012-05-03T09:29:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48256">
    <title>Undefined symbols for architecture x86_64 while building 2.4.2</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48256</link>
    <description>&lt;pre&gt;On OS X 10.7, gcc 4.2.1, with apr-1.4.5 and apr-util 1.4.1, I
encounter the following error attempting to build httpd 2.4.2. I
didn't see any architecture specific code in
srclib/apr/include/apr_file_info.h. Any thoughts?

./configure --prefix=/Users/phred/dev/httpd24 --enable-so --with-included-apr
....
make
...

gcc -std=gnu99 -g -O2     -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK
-no-cpp-precomp -DDARWIN_10    -I.
-I/Users/phred/dev/httpd-2.4.2/os/unix
-I/Users/phred/dev/httpd-2.4.2/include
-I/Users/phred/dev/httpd-2.4.2/srclib/apr/include
-I/Users/phred/dev/httpd-2.4.2/srclib/apr-util/include
-I/usr/local/include -I/Users/phred/dev/httpd-2.4.2/modules/aaa
-I/Users/phred/dev/httpd-2.4.2/modules/cache
-I/Users/phred/dev/httpd-2.4.2/modules/core
-I/Users/phred/dev/httpd-2.4.2/modules/database
-I/Users/phred/dev/httpd-2.4.2/modules/filters
-I/Users/phred/dev/httpd-2.4.2/modules/ldap
-I/Users/phred/dev/httpd-2.4.2/modules/loggers
-I/Users/phred/dev/httpd-2.4.2/modules/lua
-I/Users/phred/dev/httpd-2.4.2/modules/pr&lt;/pre&gt;</description>
    <dc:creator>Fred Moyer</dc:creator>
    <dc:date>2012-05-02T00:03:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.apache.devel/48244">
    <title>are the *.exp files still used by any platform?</title>
    <link>http://comments.gmane.org/gmane.comp.apache.devel/48244</link>
    <description>&lt;pre&gt;just curious for what the *.exp files might be used ...
to me it looks like a relic of times when the windows exports where not 
done by dllexport prefixes but with *.exp files ...
they came in 12 years back with:
http://svn.apache.org/viewvc?view=revision&amp;amp;revision=83343
and are therefore in all 2.x branches ...

Gün.



&lt;/pre&gt;</description>
    <dc:creator>Guenter Knauf</dc:creator>
    <dc:date>2012-04-29T20:43:20</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.apache.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.apache.devel</link>
  </textinput>
</rdf:RDF>

