3.2.6b
I hope everyone's having a merry Christmas or whatever other holidays you're celebrating :-) I haven't been following the list very closely lately, but it looks like last time 3.2.6b was brought up a bunch of bugs came out of the woodwork. Does it look like we're near being ready to roll 3.2.6b now? Grisha
[jira] Updated: (MODPYTHON-93) Improve util.FieldStorage efficiency
[ http://issues.apache.org/jira/browse/MODPYTHON-93?page=all ] Nicolas Lehuen updated MODPYTHON-93: Fix Version: 3.3 Version: 3.2 (was: 3.3) Improve util.FieldStorage efficiency Key: MODPYTHON-93 URL: http://issues.apache.org/jira/browse/MODPYTHON-93 Project: mod_python Type: Improvement Components: core Versions: 3.2 Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Minor Fix For: 3.3 Attachments: modpython325_util_py_dict.patch Form fields are saved as a list in a FieldStorage class instance. The class implements a __getitem__ method to provide dict-like behaviour. This method iterates over the complete list for every call to __getitem__. Applications that need to access all the fields when processing the form will show O(n^2) behaviour where n == the number of form fields. This overhead could be avoided by creating a dict (to use as an index) when the FieldStorage instance is created. Mike Looijmans has been investigating StringField and Field as well. It is probably reasonable to include information on his work in this issue as well, so that we can consider all of these efficiency issues in toto. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 3.2.6b
Hi Grisha, Having a look at the bug list I don't see anything that should prevent us from releasing the 3.2 version. There doesn't seem to be any bug due to some regression, all the new bugs were also found in 3.1. So I think we won't disappoint anyone ! I truly think we should not try to be perfect, and make this long due release of the 3.2 version. We'll have plenty of time later on to fix the next batch of bugs. Regards, Nicolas 2005/12/28, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]: I hope everyone's having a merry Christmas or whatever other holidays you're celebrating :-) I haven't been following the list very closely lately, but it looks like last time 3.2.6b was brought up a bunch of bugs came out of the woodwork. Does it look like we're near being ready to roll 3.2.6b now? Grisha
[jira] Updated: (MODPYTHON-104) Allow Python code callouts with mod_include (SSI).
[ http://issues.apache.org/jira/browse/MODPYTHON-104?page=all ]
Nicolas Lehuen updated MODPYTHON-104:
-
Fix Version: 3.3
Allow Python code callouts with mod_include (SSI).
--
Key: MODPYTHON-104
URL: http://issues.apache.org/jira/browse/MODPYTHON-104
Project: mod_python
Type: New Feature
Components: core
Reporter: Graham Dumpleton
Fix For: 3.3
The mod_include module supporting server side includes (SSI), provides a
means of registering new element tags which trigger callouts to other code in
separate Apache modules. This is used for example in mod_perl to allow Perl
language code to be used with server side includes:
!--#perl sub=MySSI::remote_host --
!--#perl arg=Hello arg=SSI arg=World
sub=sub {
my($r, @args) = @_;
print qq(@args);
}
--
An equivalent feature for Python was previously asked about on the mailing
list back in 2004:
http://www.modpython.org/pipermail/mod_python/2004-January/014832.html
Since it seems entirely reasonable that such integration of mod_python and
mod_include would be possible, thought it would be good to log it as a
possible new feature.
Because of SSI's support for basic conditionals, includes and other callout
mechanisms, would be a good quick and dirty way of doing templating without
having to resort to PSP, or other high level templating systems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: 3.2.6b
2005/12/28, Graham Dumpleton [EMAIL PROTECTED]: Grisha, I have though asked for a small change to be made which will allow me to make available a proposed new module importer when its done and for people be able to trial it without having to patch their source code. See: http://www.mail-archive.com/python-dev@httpd.apache.org/msg00904.html for details of what I was proposing. Would appreciate it if you can indicate either way whether you are okay with this small change being made or not. Graham I've tested your patch and of course it doesn't break anything in our unit tests. I can't see how it can break anything, therefore I've checked it in in the hope that it will make it for 3.2.6 final. Grisha, tell me if you disagree with that, I'll roll it back at once. Regards, Nicolas
Re: Apache2::Cookies - getting all names
Jeff wrote:
Folks,
I am finding it hard to correctly interpret the Apache2::Cookie
documentation: The docs say:
@names = $j-cookies();# all cookie names
The actual code (SVN-trunk), says this:
The final return line in sub fetch() below explains your findings.
package Apache2::Cookie::Jar;
sub cookies { Apache2::Cookie-fetch(@_) }
package Apache2::Cookie;
sub fetch {
my $class = shift;
my $req = shift;
unless (defined $req) {
my $usage = 'Usage: Apache2::Cookie-fetch($r): missing
argument $r';
$req = eval {Apache2::RequestUtil-request} or die EOD;
$usage: attempt to fetch global Apache2::RequestUtil-request failed: [EMAIL
PROTECTED]
EOD
}
$req = APR::Request::Apache2-handle($req)
unless $req-isa(APR::Request);
my $jar = $req-jar or return;
$jar-cookie_class(__PACKAGE__);
return $jar-get(shift) if @_;
return wantarray ? %$jar : $jar;
}
Given:
my $jar = Apache2::Cookie::Jar-new( $r ); # get the jar
my @names = $jar-cookies(); # all cookie names
Why does @names contain values that are not cookie names?
I am guessing that the docs are wrong on this one.
You are correct, I'll update them:
[Move this disccustion to apreq-dev (at) perl (dot) apache (dot) org CC'ed]
How about like so?
Index: Cookie.pm
===
--- Cookie.pm (revision 359541)
+++ Cookie.pm (working copy)
@@ -191,14 +191,14 @@
internal Icookies table in Capreq_jar_t, so their impact will
be noticed by all libapreq2 applications during this request.
-In list context C $jar-cookies() returns the list of names
+In list context C $jar-cookies() returns the list of cookies
for all the cookies in the jar. The order corresponds to the
order in which the cookies appeared in the incoming Cookie header.
This method will throw an C APR::Request::Error object into $@ if
the returned value(s) could be unreliable. In particular, note that
C scalar $jar-cookies(foo) will not croak if it can locate
-the a foo cookie within the jar's parsed cookie table, even if the
+a foo cookie within the jar's parsed cookie table, even if the
cookie parser has failed (the cookies are parsed in the same order
as they appeared in the Cookie header). In all other circumstances
Ccookies will croak if the parser failed to successfully parse the
@@ -209,11 +209,12 @@
$cookie = $j-cookies(foo); # first foo cookie
@cookies = $j-cookies(foo); # all foo cookies
-@names = $j-cookies();# all cookie names
+@names = $j-cookies();# all cookies
+$hashref = $j-cookies(); # hashref keyed on cookie name
+ # of all cookies
-
=head2 status
$jar-status()
Convesly, we could patch the code instead of the docs to make it do what
the docs said originally ?
Index: Cookie.pm
===
--- Cookie.pm (revision 359541)
+++ Cookie.pm (working copy)
@@ -40,7 +40,7 @@
my $jar = $req-jar or return;
$jar-cookie_class(__PACKAGE__);
return $jar-get(shift) if @_;
-return wantarray ? %$jar : $jar;
+return wantarray ? keys %$jar : $jar;
}
I'm betting the code change is what we want here.
--
Love is not the one you can picture yourself marrying,
but the one you can't picture the rest of your life without.
It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone...
Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
Re: Apache2::Cookies - getting all names
Philip M. Gollucci [EMAIL PROTECTED] writes: Index: Cookie.pm === --- Cookie.pm (revision 359541) +++ Cookie.pm (working copy) @@ -40,7 +40,7 @@ my $jar = $req-jar or return; $jar-cookie_class(__PACKAGE__); return $jar-get(shift) if @_; -return wantarray ? %$jar : $jar; +return wantarray ? keys %$jar : $jar; } I'm betting the code change is what we want here. -1. We need to fix cookies(), not fetch(). Patch cookies() so it actually works as documented. -- Joe Schaefer
Re: Apache2::Cookies - getting all names
Philip M. Gollucci [EMAIL PROTECTED] writes:
package Apache2::Cookie::Jar;
sub cookies {
my $cookies = Apache2::Cookie-fetch(@_);
## iffy to return based on documentation from $cookies and @_
}
More or less. Something like this should work:
sub cookies {
return Apache2::Cookie-fetch(@_) if @_ == 2;
my $cookies = Apache2::Cookies-fetch(@_);
return wantarray ? keys %$cookies : $cookies;
}
Of course the real problem here is test coverage. We need more cookie
tests to validate the code.
--
Joe Schaefer
DSO MPMs
Hi, In the thread called What do you want in HTTPD 2.4/3.0/X/GREEN started by Paul on December 3rd, 2005, two ideas I'd really like to get involved in were launched : - mpm-perchild - make the MPMs DSO-able Some of you may recall the design made by Michal (as SoC student) during the last ApacheCON EU (mid-july 2005) and I think making the MPMs DSO-able is a preliminary requirement to mpm-perchild development. Indeed, one of the mpm-perchild pros would be to make the childs use whatever MPM the admin wants (for example, using a very restricted user/group for a prefork MPM running PHP, and another user/group running the event MPM for other virtualhosts, etc). At first sight, I see some changes to the build process (of course), changes to the main.c file for MPM loading and running and adjustements to MPMs theirselves. I don't know how heavy those changes could be, maybe huge because we want something clean. What do you think ? Should we start working on this ? Regards, - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
Re: DSO MPMs
Maxime Petazzoni wrote: What do you think ? Should we start working on this ? I've missed the discussion, but the idea is something I definitely like. -- Love is not the one you can picture yourself marrying, but the one you can't picture the rest of your life without. It takes a minute to have a crush on someone, an hour to like someone, and a day to love someone, but it takes a lifetime to forget someone... Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com
mod_dav Code
Hello. I am new to the list because I needed to make some adjustments to the mod_dav code and I'm hoping someone can confirm what I have done makes sense.Some Info:We have anywhere from 250k to 1 million PUTs a night. Of those, we usually have about 50 that end up with a 204 status even though they don't actually exist once the upload is finished. This is obviously a huge problem.
The Setup:We have 4 web servers, and 6 file servers. This problem happens on every web and file server. The file servers are attached using NFS with the sync option. The web servers are running 2.0.55 with FC3. The file servers are mostly FC3, but two are RH9. Keep-Alive is turned on in Apache. The client software that uploads the files will retry the upload 3 times until it gets a status = 200 and 300.
More Info:I was able to narrow down the problem. It seems to only happen with some requests that first return a 500 (the Could not get next bucket brigade error). The client gets the 500, and then starts the transfer again. Apache will then respond with a 204 message, and the client will think the upload worked, even though it really didn't. Every filename uploaded is unique, and should always return a
201, so the fact that we see 204's is odd and must mean that the 500
(or first request) has not finished when the 204 (or second request)
starts.An Example For One File:The apache logs show that both requests (the 500 and 204) had the same request time, such as 2005-12-27 23:01:43 even though there's no way they could have happened at the same time, since the 500 request took 423s and the 204 took 133s. Also the 500 reported (using mod_logio) that the input was 1677285, yet the input for the 204 was 1996163.
My Solution:At the end of the dav_method_put function, I added code that actually checks the existence of the file that was uploaded, and also checks the size if it does exist.So right before the return, I added:
struct stat statinfo; if(stat(r-filename, statinfo) != 0) { err = dav_new_error(r-pool, HTTP_NOT_FOUND, 0, apr_psprintf(r-pool, File Not Found After PUT: %s,
r-filename)); return dav_handle_err(r, err, NULL); } else { //THIS SECTION HAS NEVER BEEN NEEDED if (statinfo.st_size != total_written) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, apr_psprintf(r-pool, Invalid PUT: %s (WRITTEN: %i, SIZE: %i), r-filename, total_written, statinfo.st_size)); } else {
ap_log_rerror(APLOG_MARK, APLOG_NOTICE, 0, r, apr_psprintf(r-pool, Successful PUT: %s (WRITTEN: %i), r-filename, total_written)); } }
Unfortunately, this has only decreased the number of lost files, but not eliminated it.The only thing I can think of is somehow the 500 process remains alive until the end of the 204 and then deletes the file. Also, the fact that 204 is being returned means the 204 request was writing over the 500's version of the file, so the 500 request has not finished when the 204 happens.
Thanks for your help!-Steve
Apache 2.2.0 Listen Directive
Title: Message I'm running into an issue where Apache 2.2.0 on AIX won't start if there is more than one Listen directive. According to the documentation, this should not be so. This is not the case on Solaris.This iscausing problems with regards to configuring ssl. Has anyone else seen this? Thanks in advance. , Josh.
Re: Apache 2.2.0 Listen Directive
On 12/28/05, Fenlason, Josh [EMAIL PROTECTED] wrote: I'm running into an issue where Apache 2.2.0 on AIX won't start if there is more than one Listen directive. Does it get better if you code Listen 0.0.0.0:port1 Listen 0.0.0.0:port2 ? What version of AIX (unclear that it matters)? Can you send me truss of startup using the failure configuration? truss -o /tmp/startup -f bin/apachectl start
mod_proxy, another case of ignoring the filter stack?
Hi,
I'm timing out on this one, but I thought I'd throw it in here in
case someone has a bright idea on what is actually going on...
First it doesn't seem to be the case that mod_proxy actually
sets r-status in the case of an error (service temporarily
unavailable caused by ProxyTimeout for instance). This may
not matter for a handler, but...
Secondly in case we hit the cleanup phase (for example when
we hit an error like above), mod_proxy doesn't allow filters
that were set up a chance to run.
Hereby a tiny patch to fix these issues, though I'd like some
feedback whether this is the correct spot to do this in mod_proxy.
Thanks,
Sander
Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c (revision 359556)
+++ modules/proxy/mod_proxy.c (working copy)
@@ -790,6 +790,18 @@
proxy_run_request_status(access_status, r);
+if (!r-eos_sent) {
+apr_bucket_brigade *bb;
+apr_bucket *e;
+
+r-status = access_status;
+
+bb = apr_brigade_create(r-pool, r-connection-bucket_alloc);
+e = apr_bucket_eos_create(bb-bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(bb, e);
+ap_pass_brigade(r-output_filters, bb);
+}
+
return access_status;
}
[STATUS] (httpd-2.0) Wed Dec 28 23:49:13 2005
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2005-12-18 06:19:24 -0500 (Sun, 18 Dec 2005) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Release history: 2.0.56 : in development 2.0.55 : released October 16, 2005 as GA. 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] *) mod_actions: Regression from 1.3: the file referred to must exist. Solve this by introducing the virtual modifier to the Action directive. PR 28553. modules/mappers/mod_actions.c: r1.32, r1.34 jerenkrantz: Icky side-effect of the *t == '0' check. +1: nd, jerenkrantz, wrowe, jim -0: by rbb (inconsistent to 1.3, discussion on dev@) nd: I'm going to reverse the default jerenkrantz, striker: I'm confused as to the status of this backport. *) support/check_forensic: Fix tempfile usage svn rev 125495, 126224 jerenkrantz says: r126224 fixes brokenness with r125495 on Solaris. +1: thommay, jerenkrantz, trawick trawick: which isn't portable; I've suggested a work-around on dev@
[STATUS] (httpd-2.1) Wed Dec 28 23:50:27 2005
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2005-12-16 16:06:45 -0500 (Fri, 16 Dec 2005) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained seperately and can be found at:
* docs/STATUS in this source tree, or
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.3.0 : in development
Contributors looking for a mission:
* Just do an egrep on TODO or XXX in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the PatchAvailable bugs in the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable
After testing, you can append a comment saying Reviewed and tested.
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
RELEASE SHOWSTOPPERS:
* Handling of non-trailing / config by non-default handler is broken
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2
jerenkrantz asks: Why should this block a release?
wsanchez agrees: this may be a change in behavior, but isn't
clearly wrong, and even if so, it doesn't seem like a
showstopper.
* the edge connection filter cannot be removed
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2
jerenkrantz asks: Why should this block a release?
stas replies: because it requires a rewrite of the filters stack
implementation (you have suggested that) and once 2.2 is
released you can't do that anymore.
CURRENT VOTES:
* If the parent process dies, should the remaining child processes
gracefully self-terminate. Or maybe we should make it a runtime
option, or have a concept of 2 parent processes (one being a
hot spare).
See: Message-ID: [EMAIL PROTECTED]
Self-destruct: Ken, Martin, Lars
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
/* The below was a concept on *how* to handle the problem */
Have 2 parents: +1: jim
-1: Justin, wrowe, rederpj, nd
+0: Lars, Martin (while standing by, could it do
something useful?)
* Make the worker MPM the default MPM for threaded Unix boxes.
+1: Justin, Ian, Cliff, BillS, striker, wrowe, nd
+0: BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
-0: Lars
pquerna: Do we want to change this for 2.2?
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Patches submitted to the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable
* Filter stacks and subrequests, redirects and fast redirects.
There's at least one PR that suffers from the current unclean behaviour
(which lets the server send garbage): PR 17629
nd says: Every subrequest should get its own filter stack with the
subreq_core filter as bottom-most. That filter does two things:
- swallow EOS buckets
- redirect the data stream to the upper request's (rr-main)
filter chain directly after the subrequest's starting
point.
Once we have a clean solution, we can try to optimize
it, so that the server won't be slow down too much.
* RFC 2616 violations.
Closed PRs: 15857.
Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
16138, 16139, 16140, 16142, 16518, 16520, 16521,
jerenkrantz says: need to decide how many we need to backport and/or
if these rise to showstopper status.
wrowe suggests: it would be nice to see MUST v.s. SHOULD v.s. MAY
out of this list, without reviewing them individually.
* There is a bug in how we sort some hooks, at
[PST-96582]: [STATUS] (httpd-2.0) Wed Dec 28 23:49:13 2005
== Please reply above this line == Rodent of Unusual Size, Your ticket has been successfully submitted to our Sales department. One of our staff members will review it and reply accordingly. Listed below are ticket details that you will need in order to update or check the status of this ticket from the web. Ticket Login Key: ac2541bc Ticket ID: PST-96582 Subject: [STATUS] (httpd-2.0) Wed Dec 28 23:49:13 2005 Department: Sales Team Erain You can check the status or reply to this ticket online at http://www.erain.com/eSupport/index.php?_a=tickets_m=viewmain[EMAIL PROTECTED]ticketkeyre=ac2541bc_i=PST-96582 * THE FOLLOWING ARE SOME POSSIBLE ANSWERS TO THIS TICKET FOUND IN OUR KNOWLEDGEBASE: I am unable to import Text from an AI/EPS file. http://www.erain.com/eSupport/index.php?_a=knowledgebase_j=questiondetails_i=70ticketid2=PST-96582ticketkey2=ac2541bcdoclose=1 Problem importing AI/EPS files containing text http://www.erain.com/eSupport/index.php?_a=knowledgebase_j=questiondetails_i=100ticketid2=PST-96582ticketkey2=ac2541bcdoclose=1 Drivers http://www.erain.com/eSupport/index.php?_a=knowledgebase_j=questiondetails_i=10ticketid2=PST-96582ticketkey2=ac2541bcdoclose=1 Please let us know if we can assist you any further, Electric Rain Support
