Re: Time for a new iconset?
- "Javier Llorente" wrote: > Hello list-mates, > > I think that the current icons used in directory listing look a bit > old. > Perhaps it's time to make a call for help creating a new iconset? > I am not an icon designer but I'm willing to help. > The icons I'm thinking of are the following: Hi Javier! I remember the last time you offered us your ideas, there was trouble with licencing, is that still the case? > rpm > deb > repo > ymp > bin > exe > tar.gz, tar.bz2, zip, ... > ps > ttf > odt > doc, docx > odp > ppt, pptx > ods > xls, xlsx > scd > odb > sql > svg > png > desktop, kdelnk > txt, conf > torrent > html > xml > php, phps > js > pdf > iso > cpp > pl > py > sh, run > tcl > tex > core > > and of course, up, info, folder, symlink, blank and unknown. A backlink! http://marc.info/?l=apache-httpd-dev&m=127232098429260&w=2 > I know that I'm missing some... feel free to add them to the list ;) > > So, what size should the icons have? svg and png formats are ok? What > style? > > > Cheers, > -- > Javier Llorente Bye, i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/
Time for a new iconset?
Hello list-mates, I think that the current icons used in directory listing look a bit old. Perhaps it's time to make a call for help creating a new iconset? I am not an icon designer but I'm willing to help. The icons I'm thinking of are the following: rpm deb repo ymp bin exe tar.gz, tar.bz2, zip, ... ps ttf odt doc, docx odp ppt, pptx ods xls, xlsx scd odb sql svg png desktop, kdelnk txt, conf torrent html xml php, phps js pdf iso cpp pl py sh, run tcl tex core and of course, up, info, folder, symlink, blank and unknown. I know that I'm missing some... feel free to add them to the list ;) So, what size should the icons have? svg and png formats are ok? What style? Cheers, -- Javier Llorente signature.asc Description: This is a digitally signed message part.
Re: Apache alpha and mod_jk
On 15 Oct 2010, at 10:40 PM, Graham Leggett wrote: To make this work from v2.2, the backported patches needed to make some minor changes, like reinstate CORE_PRIVATE and reverse the module definition, but otherwise can be dropped in as is: I have updated the patch with all the optimisations for the weekend, it is available here: http://people.apache.org/~minfrin/httpd-mod_cache-1023957.patch Regards, Graham --
Re: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c
On Sunday 17 October 2010, Nick Kew wrote: > On 16 Oct 2010, at 10:59, s...@apache.org wrote: > > Author: sf > > Date: Sat Oct 16 09:59:21 2010 > > New Revision: 1023227 > > > > URL: http://svn.apache.org/viewvc?rev=1023227&view=rev > > Log: > > core: Log a warning if or are used. They > > are deprecated and may go away in 2.4. > > Minor niggle ... > > > +ap_log_error(APLOG_MARK, APLOG_WARNING, 0, NULL, > > This is a startup message. Wouldn't APLOG_NOTICE be more > appropriate? Don't know. The "Ignoring deprecated use of DefaultType" and "Useless use of AllowOverride" messages also use APLOG_WARNING. And I guess it could be triggered by .htaccess parsing.
Re: [Vote] Retire 2.0.x branch?
On 18/10/2010 17:54, William A. Rowe Jr. wrote: > With a release on the way with a host of good bits, almost 2 years after its > previous release, it seems time that the group might consider the following > options... > > [ ] Leave 2.0.x open to maintenance > [X] Leave 2.0.x open to security/critical bug fixes only > [ ] Retire 2.0.x (but accumulate patches/apply_to_2.0.64) I can't really state technical reasons, but my gut says to let the public have more than one major revision fully supported at any given point in time. Issac
Re: [Vote] Retire 2.0.x branch?
> [x] Leave 2.0.x open to security/critical bug fixes only -- Eric Covener cove...@gmail.com
Re: [Vote] Retire 2.0.x branch?
On 10/18/2010 11:39 AM, Mads Toftum wrote: >> > While the 3rd option seems mighty tempting, that's moving much too fast. > How long did it take for 1.3 to change between option 2 and 3? 5 years? I think Rich's post about the pain of 1.3 -> 2.x vs 2.0 -> 2.2 summed things up pretty simply, in terms of the reason for waiting a decade to retire 1.3.
Re: [Vote] Retire 2.0.x branch?
On Mon, Oct 18, 2010 at 10:54:27AM -0500, William A. Rowe Jr. wrote: > With a release on the way with a host of good bits, almost 2 years after its > previous release, it seems time that the group might consider the following > options... > > [ ] Leave 2.0.x open to maintenance > [ ] Leave 2.0.x open to security/critical bug fixes only > [ ] Retire 2.0.x (but accumulate patches/apply_to_2.0.64) > While the 3rd option seems mighty tempting, that's moving much too fast. How long did it take for 1.3 to change between option 2 and 3? 5 years? Absolutely too long, but jumping 1 to 3 without warning seems a bit harsh to 3rd party module vendors. My suggestion would be to do 2 now and announce the switch to 3 for 12 months from now. vh Mads Toftum -- http://soulfood.dk
Re: [Vote] Retire 2.0.x branch?
On Mon, Oct 18, 2010 at 11:54 AM, William A. Rowe Jr. wrote: > With a release on the way with a host of good bits, almost 2 years after its > previous release, it seems time that the group might consider the following > options... > I vote for the most liberal choice taken by anyone, which potentially is [+1] Leave 2.0.x open to maintenance Not that I have any interest in general maintenance for 2.0.x, but I defer to a potential subset of us with appropriate karma to backport and release as they so desire, subject to the rules for such activities. What do users need to hear? We already call it legacy, we already forgo timely releases for security issues, we backport only a tiny minority of bug fixes, and so on. I guess one thing missing is that index.html should have an accurate statement if there are known security issues which have not been addressed, and/or patches need to be applied.
Re: [Vote] Retire 2.0.x branch?
On Oct 18, 2010, at 11:54 AM, William A. Rowe Jr. wrote: With a release on the way with a host of good bits, almost 2 years after its previous release, it seems time that the group might consider the following options... [ ] Leave 2.0.x open to maintenance [ ] Leave 2.0.x open to security/critical bug fixes only [X] Retire 2.0.x (but accumulate patches/apply_to_2.0.64) Yes please. Also, useful (if anecdotal) data point: While 1.3 support requests took forever to dwindle (almost, but not quite, gone now) 2.0 requests went away very rapidly with the release of 2.2. It's as though everyone considered the 1.3 -> 2.x jump a major step, but the 2.0 -> 2.2 jump pretty minor. I hardly ever encounter 2.0 users -- Rich Bowen rbo...@rcbowen.com http://drbacchus.com/
RE: [Vote] Retire 2.0.x branch?
> -Original Message- > From: William A. Rowe Jr. > Sent: Montag, 18. Oktober 2010 17:54 > To: dev@httpd.apache.org > Subject: [Vote] Retire 2.0.x branch? > > With a release on the way with a host of good bits, almost 2 > years after its > previous release, it seems time that the group might consider > the following > options... > > [ ] Leave 2.0.x open to maintenance > [+1 ] Leave 2.0.x open to security/critical bug fixes only > [ ] Retire 2.0.x (but accumulate patches/apply_to_2.0.64) > > > Regards Rüdiger
Re: [Vote] Retire 2.0.x branch?
William A. Rowe Jr. wrote: > With a release on the way with a host of good bits, almost 2 years after its > previous release, it seems time that the group might consider the following > options... > > [ ] Leave 2.0.x open to maintenance > [ ] Leave 2.0.x open to security/critical bug fixes only > [X] Retire 2.0.x (but accumulate patches/apply_to_2.0.64) We should announce end of life of 2.0 similar to what we did with 1.3, and retire it in a few month. cheers -- Lars Eilebrecht l...@eilebrecht.net
[Vote] Retire 2.0.x branch?
With a release on the way with a host of good bits, almost 2 years after its previous release, it seems time that the group might consider the following options... [ ] Leave 2.0.x open to maintenance [ ] Leave 2.0.x open to security/critical bug fixes only [ ] Retire 2.0.x (but accumulate patches/apply_to_2.0.64)
Re: svn commit: r1021946 - /httpd/httpd/trunk/modules/cache/mod_cache.c
On 18 Oct 2010, at 4:41 PM, Plüm, Rüdiger, VF-Group wrote:
Ok, I missed that. Thanks for the pointer.
But shouldn't we remove the following code from
cache_check_freshness then:
/* This value comes from the client's initial request. */
cc_req = apr_table_get(r->headers_in, "Cache-Control");
pragma = apr_table_get(r->headers_in, "Pragma");
ap_cache_control(r, &cache->control_in, cc_req, pragma, r-
>headers_in);
The above still needs to be there, as we use other information from
the request (like max-age) in the freshness check below.
ap_cache_control() has a check to ensure that it only parses the
header once, so calling it a second time isn't a problem.
if (cache->control_in.no_cache) {
if (!conf->ignorecachecontrol) {
/* Treat as stale, causing revalidation */
return 0;
}
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
"Incoming request is asking for a uncached version of "
"%s, but we have been configured to ignore it and "
"serve a cached response anyway",
r->unparsed_uri);
}
In theory, the above is caught by ap_cache_check_allowed(), so doesn't
do anything, on condition we always call ap_cache_check_allowed()
before running cache_check_freshness().
Yeah, the patch below makes the behaviour consistent and makes sense.
Will commit it.
I've found some more stuff that can be optimised in
cache_check_freshness(), will look at this in more detail tonight.
Regards,
Graham
--
RE: svn commit: r1021946 - /httpd/httpd/trunk/modules/cache/mod_cache.c
> -Original Message-
> From: Graham Leggett
> Sent: Montag, 18. Oktober 2010 16:11
> To: dev@httpd.apache.org
> Subject: Re: svn commit: r1021946 -
> /httpd/httpd/trunk/modules/cache/mod_cache.c
>
> On 18 Oct 2010, at 8:36 AM, Ruediger Pluem wrote:
>
> >> If the client specified no-cache, the cache steps down
> completely,
> >> and
> >> the client is guaranteed fresh content from the source
> server (as per
> >> the RFC). The cache will only revalidate if you say max-age=X (or
> >> other
> >> valid caching tokens).
> >
> > I cannot follow that. The above code means that
> > cache_check_freshness returns
> > 0 and thus we replace the client supplied conditionals with our own:
>
> mod_cache used to do this, but not any more as it's an RFC
> violation.
> Now, if the client supplies no-cache, this is caught by a function
> called ap_cache_check_allowed(), which if not allowed, causes no
> attempt to be made to open or touch an existing cached file. Look
> further upwards in cache_select(), you'll see the call to
> ap_cache_check_allowed():
Ok, I missed that. Thanks for the pointer.
But shouldn't we remove the following code from cache_check_freshness then:
/* This value comes from the client's initial request. */
cc_req = apr_table_get(r->headers_in, "Cache-Control");
pragma = apr_table_get(r->headers_in, "Pragma");
ap_cache_control(r, &cache->control_in, cc_req, pragma, r->headers_in);
if (cache->control_in.no_cache) {
if (!conf->ignorecachecontrol) {
/* Treat as stale, causing revalidation */
return 0;
}
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
"Incoming request is asking for a uncached version of "
"%s, but we have been configured to ignore it and "
"serve a cached response anyway",
r->unparsed_uri);
}
>
> So if I'm understanding you correctly, the issue is with the
> different
> handling of the check for "must-revalidate"?
Yes.
>
> Hmmm.
>
> If "must-revalidate" is present in the original cached response, in
> both cases, we don't serve the stale-cached-content, which is
> correct
> according to the definition of must-revalidate.
>
> This makes the invalidation of the stale response academic from the
> client's point of view, as this stale response, which contains the
> "must-revalidate", will never be served to the client while
> the error
> persists.
>
> This is however inconsistent as you've pointed out, and needs to be
> fixed.
>
> From the server's point of view, invalidating the cached
> entry means
> that when the server comes back, it will need to serve a 200
> response
> from scratch, and if our server is returning 5xx errors this is less
> than ideal. I think we should remove the remove_url filter in both
> cases, so that we're consistent, like below.
>
> Does this make sense?
Yeah, the patch below makes the behaviour consistent and makes sense.
Thanks for your patience and for explaining.
>
> Index: modules/cache/mod_cache.c
> ===
> --- modules/cache/mod_cache.c (revision 1023462)
> +++ modules/cache/mod_cache.c (working copy)
> @@ -1595,6 +1595,8 @@
> if (dummy) {
> cache_request_rec *cache = (cache_request_rec *) dummy;
>
> +ap_remove_output_filter(cache->remove_url_filter);
> +
> if (cache->stale_handle && cache->save_filter
> && !cache->stale_handle->cache_obj-
> >info.control.must_revalidate
> && !cache->stale_handle->cache_obj-
> >info.control.proxy_revalidate) {
> @@ -1627,8 +1629,6 @@
> "110 Response is stale");
> }
>
> -ap_remove_output_filter(cache->remove_url_filter);
> -
> cache_run_cache_status(
> cache->handle,
> r,
>
Regards
Rüdiger
Re: svn commit: r1021946 - /httpd/httpd/trunk/modules/cache/mod_cache.c
On 18 Oct 2010, at 8:36 AM, Ruediger Pluem wrote:
If the client specified no-cache, the cache steps down completely,
and
the client is guaranteed fresh content from the source server (as per
the RFC). The cache will only revalidate if you say max-age=X (or
other
valid caching tokens).
I cannot follow that. The above code means that
cache_check_freshness returns
0 and thus we replace the client supplied conditionals with our own:
mod_cache used to do this, but not any more as it's an RFC violation.
Now, if the client supplies no-cache, this is caught by a function
called ap_cache_check_allowed(), which if not allowed, causes no
attempt to be made to open or touch an existing cached file. Look
further upwards in cache_select(), you'll see the call to
ap_cache_check_allowed():
int cache_select(cache_request_rec *cache, request_rec *r)
{
cache_provider_list *list;
apr_status_t rv;
cache_handle_t *h;
if (!cache) {
/* This should never happen */
ap_log_rerror(APLOG_MARK, APLOG_ERR, APR_EGENERAL, r,
"cache: No cache request information available for key"
" generation");
return DECLINED;
}
if (!cache->key) {
rv = cache_generate_key(r, r->pool, &cache->key);
if (rv != APR_SUCCESS) {
return DECLINED;
}
}
if (!ap_cache_check_allowed(cache, r)) {
return DECLINED;
}
/* go through the cache types till we get a match */
h = apr_palloc(r->pool, sizeof(cache_handle_t));
list = cache->providers;
while (list) {
switch ((rv = list->provider->open_entity(h, r, cache->key))) {
We do it the same way in both cases, the remove_url filter is
removed in
the ap_die() case on line 1630, and in the mod_proxy case inside
save_filter on line 791.
Sorry for being a PITA, but IMHO we do not:
If a bug exists, we must find it :)
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_cache.c?rev=1021946&r1=1021945&r2=1021946&view=diff
=
=
=
=
=
=
=
=
==
--- httpd/httpd/trunk/modules/cache/mod_cache.c (original)
+++ httpd/httpd/trunk/modules/cache/mod_cache.c Tue Oct 12 22:54:06
2010
@@ -779,6 +779,61 @@ static int cache_save_filter(ap_filter_t
dconf = ap_get_module_config(r->per_dir_config, &cache_module);
+/* RFC2616 13.8 Errors or Incomplete Response Cache Behavior:
+ * If a cache receives a 5xx response while attempting to
revalidate an
+ * entry, it MAY either forward this response to the requesting
client,
+ * or act as if the server failed to respond. In the latter
case, it MAY
+ * return a previously received response unless the cached entry
+ * includes the "must-revalidate" cache-control directive (see
section
+ * 14.9).
+ *
+ * This covers the case where an error was generated behind us,
for example
+ * by a backend server via mod_proxy.
+ */
+if (dconf->stale_on_error && r->status >=
HTTP_INTERNAL_SERVER_ERROR) {
+
+ap_remove_output_filter(cache->remove_url_filter);
+
+if (cache->stale_handle && !ap_cache_liststr(
+NULL,
+apr_table_get(cache->stale_handle->resp_hdrs,
"Cache-Control"),
+"must-revalidate", NULL)) {
+const char *warn_head;
Modified: httpd/httpd/trunk/modules/cache/mod_cache.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_cache.c?rev=1021546&r1=1021545&r2=1021546&view=diff
=
=
=
=
=
=
=
=
==
--- httpd/httpd/trunk/modules/cache/mod_cache.c (original)
+++ httpd/httpd/trunk/modules/cache/mod_cache.c Mon Oct 11 23:32:56
2010
+/* RFC2616 13.8 Errors or Incomplete Response Cache Behavior:
+ * If a cache receives a 5xx response while attempting to
revalidate an
+ * entry, it MAY either forward this response to the requesting
client,
+ * or act as if the server failed to respond. In the latter
case, it MAY
+ * return a previously received response unless the cached entry
+ * includes the "must-revalidate" cache-control directive (see
section
+ * 14.9).
+ */
+apr_pool_userdata_get(&dummy, CACHE_CTX_KEY, r->pool);
+if (dummy) {
+cache_request_rec *cache = (cache_request_rec *) dummy;
+
+if (cache->stale_handle && cache->save_filter && !
ap_cache_liststr(
+NULL, apr_table_get(cache->stale_handle->resp_hdrs,
+"Cache-Control"), "must-revalidate", NULL)) {
+const char *warn_head;
+
+/* morph the current save filter into the out filter,
and serve from
+ * cache.
+ */
+cache->handle = cache->stale_handle;
+if (r->main) {
+cache->save_filter->frec =
cache_out_subreq_filter_handle;
+
Re: How to restore HTTP settings/sessions during GRACEFUL restart
On Mon, Oct 18, 2010 at 4:25 AM, Petr Hracek wrote: > Dear apache2 users, > > sorry for bother you with this issue but I need help from the apache2 > developers. > In my module I am setting some HTTP settings like sessions and HTTP Title etc. > Please take this to the modules-dev list. where/how/with what lifetime? > When I am calling sending SIGHUP or restarting apache2 over apache2ctl > then setting are lost. > That's correct behaviour. > > But when I am sending SIGUSR1 or apache2ctl -k graceful HTTP settings > and sessions are lost as well > and that's not correct behaviour. What settings? What session? Are they lost in the in the children that are exiting or in the new children that come up with the new configuration? If it's the latter, why do you expect them to still be there?
Re: [PATCH] mod_cgi: Mitigating some header injections by dropping invalid headers?
On Tuesday 12 October 2010 19:49:02 Malte S. Stretz wrote:
> On Tuesday 12 October 2010 18:13:46 William A. Rowe Jr. wrote:
> > On 10/12/2010 10:06 AM, Dirk-Willem van Gulik wrote:
> > > On 12 Oct 2010, at 15:30, Malte S. Stretz wrote:
> > >> I had a quick look at the Apache source and the solution was
> > >> simple:
> > >> Just drop headers which contain any character outside the range
> > >>
> > >> [a-zA-Z0-9-]. The patch against trunk is attached.
> > >
> > > This made me think of something we had a while ago; and after
> > > checking the logs - big +1 from me!
> >
> > Agreed, with a caviat... we aught to be able to toggle this for the
> > rare but significant legacy app that requires it... which implies a
> > per-dir flag that can override just one CGI script out of an entire
> > server.
>
> I think an option is not needed as there is a workaround. Eg. to make
> an Accept_Encoding header work:
>
> SetEnvIfNoCase ^Accept.Encoding$ ^(.*)$ fix_header=$1
> RequestHeader set Accept-Encoding %{fix_header}e env=fix_header
>[...]
Attached is an updated patch which also updates the docs. It also
includes the commit message I tried to commit it with (didn't realize that
there are per-project commit flags).
Is the documented workaround good enough or should something like an map-
broken-headers environment variable be introduced?
Cheers,
Malte
Be more strict when mapping HTTP headers to env variables.
While this prevents some potential cross-site-scripting attacks (cf.
)
it might break some broken clients. This fact is documented in
various places and a workaround is available in env.html.
On the dev list it was suggested that instead of a workaround an
option should be introduced. Please yell if thats the conensus.
Somebody should proofread my English :)
--This line, and those below, will be ignored--
Mserver/util_script.c
Mdocs/manual/env.xml
Mdocs/manual/new_features_2_4.xml
Mdocs/manual/howto/cgi.xml
Index: server/util_script.c
===
--- server/util_script.c (revision 1023678)
+++ server/util_script.c (working copy)
@@ -67,11 +67,14 @@
*cp++ = '_';
while ((c = *w++) != 0) {
-if (!apr_isalnum(c)) {
+if (apr_isalnum(c)) {
+*cp++ = apr_toupper(c);
+}
+else if (c == '-') {
*cp++ = '_';
}
else {
-*cp++ = apr_toupper(c);
+return NULL;
}
}
*cp = 0;
@@ -175,8 +178,8 @@
continue;
}
#endif
-else {
-apr_table_addn(e, http2env(r->pool, hdrs[i].key), hdrs[i].val);
+else if ((env_temp = http2env(r->pool, hdrs[i].key)) != NULL) {
+apr_table_addn(e, env_temp, hdrs[i].val);
}
}
Index: docs/manual/env.xml
===
--- docs/manual/env.xml (revision 1023678)
+++ docs/manual/env.xml (working copy)
@@ -140,6 +140,13 @@
not be a number. Characters which do not match this
restriction will be replaced by an underscore when passed to
CGI scripts and SSI pages.
+
+ A special case are HTTP headers which are passed to CGI
+ scripts and the like via environment variables (see below).
+ They are converted to uppercase and only dashes are replaced with
+ underscores; if the header contains any other (invalid) character,
+ the whole header is silently dropped. See
+ below for a workaround.
The SetEnv directive runs
late during request processing meaning that directives such as
@@ -423,6 +430,32 @@
Examples
+
+ Passing broken headers to CGI scripts
+
+ Starting with version 2.4, Apache is more strict about how HTTP
+ headers are converted to environment variables in mod_cgi
+ and other modules: Previously any invalid characters
+ in header names were simply translated to underscores. This allowed
+ for some potential cross-site-scripting attacks via header injection
+ (see http://events.ccc.de/congress/2007/Fahrplan/events/2212.en.html";>
+ Unusual Web Bugs, slide 19/20).
+
+ If you have to support a client which sends broken headers and
+ which can't be fixed, a simple workaround involving mod_setenvif
+ and mod_header allows you to still accept
+ these headers:
+
+
+#
+# The following works around a client sending a broken Accept_Encoding
+# header.
+#
+SetEnvIfNoCase ^Accept.Encoding$ ^(.*)$ fix_accept_encoding=$1
+RequestHeader set Accept-Encoding %{fix_accept_encoding}e env=fix_accept_encoding
+
+
+
Changing protocol behavior with misbehaving clients
Index: docs/manual/new_features_2_4.xml
===
--- docs/manual
Re: [vote] Release mod_ftp 1.0.0 as GA
On 18/10/2010 10:40, William A. Rowe Jr. wrote: > On 10/7/2010 9:23 PM, William A. Rowe Jr. wrote: >> After some discussion on list about the numbering and quality of mod_ftp >> today, it seems this is an appropriate time to consider GA, candidate >> tarballs are up at http://httpd.apache.org/dev/dist/mod_ftp/ - so please >> vote... >> >> +/-1 >> [ ] Release mod_ftp 1.0.0 as GA > +1 here. We have 2 additional +1's, but not from PMC members. > > If two more could look at this, it has now stretched on over 10 days without > a vote. The changes are minimal to the 0.9.6-beta which has been available > now 2 years, so this would be a good time to declare it baked, IMHO. +1
Re: [vote] Release mod_ftp 1.0.0 as GA
On 10/7/2010 9:23 PM, William A. Rowe Jr. wrote: > After some discussion on list about the numbering and quality of mod_ftp > today, it seems this is an appropriate time to consider GA, candidate > tarballs are up at http://httpd.apache.org/dev/dist/mod_ftp/ - so please > vote... > > +/-1 > [ ] Release mod_ftp 1.0.0 as GA +1 here. We have 2 additional +1's, but not from PMC members. If two more could look at this, it has now stretched on over 10 days without a vote. The changes are minimal to the 0.9.6-beta which has been available now 2 years, so this would be a good time to declare it baked, IMHO.
Re: [Vote] httpd 2.2.17 release
On 10/14/2010 3:51 PM, William A. Rowe Jr. wrote: > > +/-1 > [+1] Release httpd 2.2.17 as GA It appears we have the necessary votes for release. Moving things along to the mirrors, now.
Re: [Vote] httpd 2.0.64 release
On 10/14/2010 3:50 PM, William A. Rowe Jr. wrote: > Candidate binaries are available from http://httpd.apache.org/dev/dist/ - > these do not yet constitute ASF releases. Win32 specific artifacts (-src, > x86 binary distribution) will follow in the coming day. > > +/-1 > [+1] Release httpd 2.0.64 as GA Sorry for the miss on a copyright date. These should all be freshened to 2010 to reflect the most recent release. But it doesn't strike me as a showstopper. With that, I'm sending things off to the mirror, it appears we have the necessary votes.
How to restore HTTP settings/sessions during GRACEFUL restart
Dear apache2 users, sorry for bother you with this issue but I need help from the apache2 developers. In my module I am setting some HTTP settings like sessions and HTTP Title etc. When I am calling sending SIGHUP or restarting apache2 over apache2ctl then setting are lost. That's correct behaviour. But when I am sending SIGUSR1 or apache2ctl -k graceful HTTP settings and sessions are lost as well and that's not correct behaviour. Is there any interface how to catch sessions and HTTP Title during apache2 graceful restart so that after restarting apache2 sessions and HTTP Title will be still existing and working? Is there any simple module/ example where is this situation described? Thank you in advance -- Best Regards / S pozdravem Petr Hracek
