DO NOT REPLY [Bug 37682] New: - [ArgumentNullException: Value cannot be null.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37682. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37682 Summary: [ArgumentNullException: Value cannot be null. Product: Apache mod_aspdotnet Version: 2.0.0 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: mod_aspdotnet AssignedTo: cli-dev@httpd.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] I try to install simple web application ngallery based on apache web server and mod_aspdotnet, but i got the following error. (ngallery works with XSP on memo and IIS) Value cannot be null. Parameter name: str Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.ArgumentNullException: Value cannot be null. Parameter name: str Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [ArgumentNullException: Value cannot be null. Parameter name: str] System.Security.Permissions.FileIOPermission.HasIllegalCharacters(String[] str) +231 System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess access, String[] pathListOrig, Boolean checkForDuplicates, Boolean needFullPath, Boolean copyPathList) +88 System.Web.HttpRequest.MapPath(String virtualPath, String baseVirtualDir, Boolean allowCrossAppMapping) +305 System.Web.HttpServerUtility.MapPath(String path) +61 nGallery._default.Page_Load(Object sender, EventArgs e) +66 System.EventHandler.Invoke(Object sender, EventArgs e) +0 System.Web.UI.Control.OnLoad(EventArgs e) +55 System.Web.UI.Control.LoadRecursive() +27 System.Web.UI.Page.ProcessRequestMain() +731 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[jira] Commented: (MODPYTHON-94) Calling APR optional functions provided by mod_ssl
[ http://issues.apache.org/jira/browse/MODPYTHON-94?page=comments#action_12358781 ] Graham Dumpleton commented on MODPYTHON-94: --- I thought about the ctypes approach when I proposed the first code I referenced. The problem was how you dealt with the complexity of setting up a call which had to refer to data within the internal mod_python request object C structure which wasn't otherwise visible at the Python layer through the mod_python Python request object. Eg. variable_value = ssl_var_lookup( request_object-request_rec-pool, request_object-request_rec-server, request_object-request_rec-connection, request_object-request_rec, variable_name); It may well be possible, but it seemed to me to be quite messy and quite prone to bugs/problems due to the disconnect between the C code and Python code. Ie., you change the C structure to add/change stuff and you have to remember to change any Python code which is somehow using ctypes and defining offsets within the structure. Seemed more trouble that it was worth. Calling APR optional functions provided by mod_ssl -- Key: MODPYTHON-94 URL: http://issues.apache.org/jira/browse/MODPYTHON-94 Project: mod_python Type: New Feature Components: core Versions: 3.2 Environment: Apache 2 Reporter: Deron Meranda Attachments: modpython4.tex.patch, requestobject.c.patch mod_python is not able to invoke APR Optional Functions. There are some cases however where this could be of great benifit. For example, consider writing an authentication or authorization handler which needs to determine SSL properties (even if to just answer the simple question: is the connection SSL encrypted). The normal way of looking in the subprocess_env for SSL_* variables does not work in those early handler phases because those variables are not set until the fixup phase. The mod_ssl module though does provide both a ssl_is_https() and ssl_var_lookup() optional functions which can be used in earlier phases. For example look at how mod_rewrite calls those; using the APR_DECLARE_OPTIONAL_FN and APR_RETRIEVE_OPTIONAL_FN macros. I can see how it might be very hard to support optional functions in general because of the C type linkage issue, but perhaps a select few could be coded directly into mod_python. -- 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: Various musings about the request URL / URI / whatever
Nicolas Lehuen wrote:
Hi,
Is it me or is it quite tiresome to get the URL that called us, or get
the complete URL that would call another function ?
When performing an external redirect (using mod_python.util.redirect for
example), we MUST (as per RFC) provide a full URL, not a relative one.
Instead of util.redirect(req,'/foo/bar.py'), we should write
util.redirect(req,'https://whatever:8443/foo/bar.py').
The problem is, writing this is always tiresome, as it means building a
string like this :
def current_url(req):
req.add_common_vars()
current_url = []
# protocol
if req.subprocess_env.get('HTTPS') == 'on':
current_url.append('https')
default_port = 443
else:
current_url.append('http')
default_port = 80
current_url.append('://')
# host
current_url.append(req.hostname)
# port
port = req.connection.local_addr[1]
if port != default_port:
current_url.append(':')
current_url.append(str(port))
# URI
current_url.append(req.uri)
return ''.join(current_url)
So I have two questions :
First question, is there a simpler way to do this ? Ironically, when
using mod_rewrite, you get an environment variable named SCRIPT_URI
which is precisely what I need (SCRIPT_URL, also added by mod_rewrite,
is equivalent to req.uri... Don't ask we why). But relying on it isn't
safe since mod_rewrite isn't always used.
I guess you could just assemble the parts from the req.parsed_uri tuple,
except that apache doesn't actually fill in parsed_uri. :(
Second question, if there isn't any simpler way to do this, should we
add it to mod_python ? Either as a function like above in
mod_python.util, or as a member of the request object (named something
like url to match the other member named uri, but that's just teasing).
I'm not against it, but for my purposes I think it would be more useful
for parsed_uri to just work properly.
And third question (in pure Spanish inquisition style) : why is
req.parsed_uri returning me a tuple full of Nones except for the uri and
path_info part ?
It comes from apache that way. I sure don't know why though. Maybe we're
missing some magic apache call that would fill it in?
Ah, fourth question : why are we (mod_python, mod_rewrite and the CGI
environment variables) using the terms URI and URL to distinguish
between a full, absolute resource path and a path relative to the
server, whereas the definition of URLs and URIs is very vague and
nothing close to this
(http://www.w3.org/TR/uri-clarification/#contemporary) ? Shouldn't we
save our souls and a lot of saliva by choosing better names ?
Strangely I was reading the cited page just last week, for perhaps the
100th time. I keep hoping I'll find enlightment but alas no. The danger
of choosing new names (ie absolute_thingy or relative_thingy) is that
we also add another layer of confusion. I'm not saying new names are a
bad idea, just that we need to be very careful.
OK, OK, fifth question : we made req.filename and other members
writable. But when those attributes are changed, as Graham noted a while
ago, the other dependent ones aren't, leading to inconsitencies (for
example, if you change req.filename, req.canonical_filename isn't
changed). Should we try to solve this and provide clear definition of
the various parts of a request for mod_python 3.3 ?
That would make sense. I'm wondering how often people make use of
req.canonical_filename (CFN*)? Also, just how would the CFN be
adjusted if the user code changes req.filename, since the user is free
to put any string in there they want? Maybe CFN just gets changed to the
same string. Hopefully Graham will shed some light on this, since it was
his use case.
Regards,
Jim
* Because I can't type canonical_filename the same way twice. Stupid
fingers.
Re: Various musings about the request URL / URI / whatever
On Tue, 29 Nov 2005, Nicolas Lehuen wrote:
def current_url(req):
[snip]
# host
current_url.append(req.hostname)
[snip]
This part isn't going to work reliably if you are not using virtual hosts
and just bind to an IP number. Deciphering the URL is an impossible task -
I used to have similar code in my apllications, but lately I realized that
it does not work reliably and it is much simpler to just treat it as a
configuration item...
First question, is there a simpler way to do this ? Ironically, when using
mod_rewrite, you get an environment variable named SCRIPT_URI which is
precisely what I need (SCRIPT_URL, also added by mod_rewrite, is equivalent
to req.uri... Don't ask we why). But relying on it isn't safe since
mod_rewrite isn't always used.
well - here's how it does it.
/*
* create the SCRIPT_URI variable for the env
*/
/* add the canonical URI of this URL */
thisserver = ap_get_server_name(r);
port = ap_get_server_port(r);
if (ap_is_default_port(port, r)) {
thisport = ;
}
else {
apr_snprintf(buf, sizeof(buf), :%u, port);
thisport = buf;
}
thisurl = apr_table_get(r-subprocess_env, ENVVAR_SCRIPT_URL);
/* set the variable */
var = apr_pstrcat(r-pool, ap_http_method(r), ://, thisserver, thisport,
thisurl, NULL);
apr_table_setn(r-subprocess_env, ENVVAR_SCRIPT_URI, var);
/* if filename was not initially set,
* we start with the requested URI
*/
if (r-filename == NULL) {
r-filename = apr_pstrdup(r-pool, r-uri);
rewritelog(r, 2, init rewrite engine with requested uri %s,
r-filename);
}
Second question, if there isn't any simpler way to do this, should we add it
to mod_python ? Either as a function like above in mod_python.util, or as a
member of the request object (named something like url to match the other
member named uri, but that's just teasing).
I don't know... Since the result is going to be half-baked... I think a
more interesting and mod_python-ish thing to do would be to expose all the
API's used in the above code (e.g. ap_get_server_name, ap_is_default_port,
ap_http_method) FIRST, then think about this.
And third question (in pure Spanish inquisition style) : why is
req.parsed_uri returning me a tuple full of Nones except for the uri and
path_info part ?
This is an httpd question most likely...
Ah, fourth question : why are we (mod_python, mod_rewrite and the CGI
environment variables) using the terms URI and URL to distinguish
between a full, absolute resource path and a path relative to the server,
whereas the definition of URLs and URIs is very vague and nothing close to
this (http://www.w3.org/TR/uri-clarification/#contemporary) ? Shouldn't we
save our souls and a lot of saliva by choosing better names ?
No, we (mod_python) should just use the exact same name that httpd uses.
If we come up better names, then it's just going to make it even more
confusing.
OK, OK, fifth question : we made req.filename and other members writable.
But when those attributes are changed, as Graham noted a while ago, the
other dependent ones aren't, leading to inconsitencies (for example, if you
change req.filename, req.canonical_filename isn't changed). Should we try to
solve this
The solutions is to make req.canonical_filename writable too and document
that if you change req.filename, you may consider changing
canonical_filename as well and what will happen if you do not.
and provide clear definition of the various parts of a request
for mod_python 3.3 ?
Yes, that'd be good :)
Grisha
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
On Tue, 29 Nov 2005, Jim Gallacher wrote: I still think the correct place to create the index dictionary is in the __init__ phase. Using the dictionary-on-demand idea only improves performance on the second access to a form field. For the first access you are still iterating through the whole list for each field name. I am still not convinced we need an index. I'd like to see some concrete proof that we're not engaging in overoptimization here - is this really a bottleneck for anyone? If we're concerned (and I'm not at this point) that FieldStorage is too slow, we should just rewrite the whole thing in C :-) Grisha
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Jim Gallacher wrote: Nick wrote: Just one comment. It seems like it would be better just to make add_method inline, since everything else in __init__ is, and it never gets called from anywhere else. add_method? Haha, thanks, I haven't had coffee yet. The add_item method, that is. :) I also like properties, but doesn't that cause a problem if someone chooses to subclass FieldStorage? It could if you didn't realize it was a property. But you can always override a property with another property. Nick
Re: Various musings about the request URL / URI / whatever
Daniel J. Popowich wrote: Jim Gallacher writes: Nicolas Lehuen wrote: Second question, if there isn't any simpler way to do this, should we add it to mod_python ? Either as a function like above in mod_python.util, or as a member of the request object (named something like url to match the other member named uri, but that's just teasing). I'm not against it, but for my purposes I think it would be more useful for parsed_uri to just work properly. Here, here!! I've wanted parsed_uri to work as expected for quite some time...I'm actually in a position where I could devote some time to tracking this down. If apache doesn't provide it, I think mod_python should at least fill it in, right? +1 Can someone knudge me in the right direction to start? Haven't poked around apache source and/or developer docs in years. All I can say is grep is your friend. :) I've found http://docx.webperf.org to be useful. Unfortunately you can only drill down into the header files, not c files (unless I'm missing something). I might even be tempted to generate my own local copy of the apache docs using doxygen so that the c-files get included. I've been playing with doxygen + mod_python and it's pretty cool. Searching docx for parse_uri turns up ap_parse_uri. http://docx.webperf.org/group__APACHE__CORE__PROTO.html#ga44 Grab the src and put grep to work. I'll dig in and help any way I can. Jim
Re: Various musings about the request URL / URI / whatever
Gregory (Grisha) Trubetskoy wrote: On Tue, 29 Nov 2005, Jim Gallacher wrote: Daniel J. Popowich wrote: Here, here!! I've wanted parsed_uri to work as expected for quite some time...I'm actually in a position where I could devote some time to tracking this down. If apache doesn't provide it, I think mod_python should at least fill it in, right? +1 I don't know what the specific issue is with parsed_uri, if this is a mod_python bug it should just be fixed BUT if this is an issue with httpd, I don't think we should cover the problem up by having mod_python fix it. Since we are part of the HTTP Server project, we should just fix it in httpd. Either way, it should be fixed. In case anyone is not familiar with the issue, a request for http://example.com/tests/mptest?view=form currently gives a tuple that looks something like this: (None, None, None, None, None, None, '/tests/mptest', 'view=form', None) which is not what we expect. This is what the mod_python docs have to say: parsed_uri Tuple. The URI broken down into pieces. (scheme, hostinfo, user, password, hostname, port, path, query, fragment). The apache module defines a set of URI_* constants that should be used to access elements of this tuple. Example: fname = req.parsed_uri[apache.URI_PATH] (Read-Only) Jim
Re: Various musings about the request URL / URI / whatever
Gregory (Grisha) Trubetskoy writes: On Tue, 29 Nov 2005, Nicolas Lehuen wrote: If I understand you correctly, req.hostname is not reliable in case where virtual hosting is not used. What about server.server_hostname, which seems to be used by the code from mod_rewrite you posted below ? Can it be used reliably ? I don't think so. if I do this: telnet some.host.com 80 GET /index.html How would apache know what the hostname is? By the Host header. I've been looking into this issue tonight and think I have the answers (but it's really late, so I'll save the gory details for tomorrow). In brief: typically, req.hostname is set from the Host header and, in fact, when I telnet to apache and issue a GET by hand, if I don't send the Host header, apache barfs with a 400, Bad Request, response. (apache 2.0.54, debian testing) As for the larger issue at hand: the reason req.parsed_uri is not filled in is because browsers don't send the info in the GET, e.g., browsers send this: GET /index.py?a=bc=d HTTP/1.1 not GET http://user:[EMAIL PROTECTED]:80/index.py?a=bc=d#here HTTP/1.1 if they did, parsed_uri would be filled in. req.unparsed_uri is whatever the word after GET in the http protocol exchange; req.parsed_uri is the parsing of that word. Given the full URI spec: SCHEME://[USER[:[EMAIL PROTECTED]:PORT]/PATH?QUERY#FRAGMENT you can see where eight of the nine elements of the parsed_uri tuple come from; the ninth, hostinfo, is the combination of [USER[:[EMAIL PROTECTED]:PORT] (everything between // and /). Unfortunately, browsers only send: /PATH?QUERY and that's why we only ever see it in unparsed_uri and parsed_uri. Again, lots more to share...in the morrow... Daniel Popowich --- http://home.comcast.net/~d.popowich/mpservlets/
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Just one comment. It seems like it would be better just to make add_method inline, since everything else in __init__ is, and it never gets called from anywhere else. s/_method/_field/g The thing I had in mind when I built the add_field method was that I could subclass FieldStorage and give the page handler more control over what is happening. This was convenient for the thing that got this all started: Posting large files. In fact, I intended add_field to replace the make_file function. What I had in mind is that you override the add_field function to get context information (e.g. user name, upload directory and such) before the file upload comes in, so that you can put the upload where it belongs. With the two callbacks, you can create the same effect, so it was no longer nessecary. Also, the add_field is referred at least twice and I don't like duplicating code. -- Mike Looijmans Philips Natlab / Topic Automation
Re: Various musings about the request URL / URI / whatever
Daniel J. Popowich wrote: By the Host header. I've been looking into this issue tonight and think I have the answers (but it's really late, so I'll save the gory details for tomorrow). In brief: typically, req.hostname is set from the Host header and, in fact, when I telnet to apache and issue a GET by hand, if I don't send the Host header, apache barfs with a 400, Bad Request, response. (apache 2.0.54, debian testing) It will only do that if you claim to be a HTTP/1.1 client. If you send GET / HTTP/1.0 it will not complain about the host header. Sending: GET / HTTP/1.1 will get you a 400 response, because you MUST supply it (says RFC 2068, and whatever superseded that one). There is more you must do to be able to call yourself HTTP/1.1 by the way, such as keep-alive connections and chunked encoding. -- Mike Looijmans Philips Natlab / Topic Automation
Re: [vote] 2.2.0 tarballs
Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: * svn r348009: Added AP_DECLARE to mod_dbd exported functions. No functional changes for most operating systems. * svn r348055 and 348029: Netware specific fixes for a missing SSL CGI variable, and for linking to the correct sockets library. * Several Documentation only commits. (Including updating URLs in the README, UPDATING, etc..) -Paul
Various musings about the request URL / URI / whatever
Hi,Is it me or is it quite tiresome to get the URL that called us, or get the complete URL that would call another function ?When performing an external redirect (using
mod_python.util.redirect for example), we MUST (as per RFC) provide a full URL, not a relative one. Instead of util.redirect(req,'/foo/bar.py'), we should write
util.redirect(req,'https://whatever:8443/foo/bar.py').The problem is, writing this is always tiresome, as it means building a string like this :
def current_url(req):req.add_common_vars()current_url = []# protocolif req.subprocess_env.get('HTTPS') == 'on':current_url.append('https')
default_port = 443else:current_url.append('http')default_port = 80current_url.append('://')# hostcurrent_url.append(req.hostname)# port
port = req.connection.local_addr[1]if port != default_port:current_url.append(':')current_url.append(str(port))# URIcurrent_url.append(req.uri)return ''.join(current_url)
So I have two questions :
First question, is there a simpler way to do this ? Ironically, when using mod_rewrite, you get an environment variable named
SCRIPT_URI which is precisely what I need (SCRIPT_URL, also added by mod_rewrite, is equivalent to
req.uri... Don't ask we why). But relying on it isn't safe since mod_rewrite isn't always used.
Second question, if there isn't any simpler way to do this, should we add it to mod_python ? Either as a function like above in mod_python.util, or as a member of the request object (named something like
url to match the other member named uri, but that's just teasing).
And third question (in pure Spanish inquisition style) : why is req.parsed_uri returning me a tuple full of Nones except for the uri and path_info part ?
Ah, fourth question : why are we (mod_python, mod_rewrite and the CGI environment variables) using the terms URI and URL
to distinguish between a full, absolute resource path and a path
relative to the server, whereas the definition of URLs and URIs is very
vague and nothing close to this
(http://www.w3.org/TR/uri-clarification/#contemporary) ? Shouldn't we
save our souls and a lot of saliva by choosing better names ?
OK, OK, fifth question : we made req.filename
and other members writable. But when those attributes are changed, as
Graham noted a while ago, the other dependent ones aren't, leading to
inconsitencies (for example, if you change req.filename,
req.canonical_filename isn't changed). Should we try to solve this and provide clear definition of the various parts of a request for mod_python 3.3 ?
Regards,
Nicolas
Re: [vote] 2.2.0 tarballs
On Mon, Nov 28, 2005 at 11:55:48PM -0800, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. +1 for GA based on my previous tests with 2.1.10 and a visual inspection of the recursive diff between the 2.1.10 and 2.2.0 tarballs (which is only 314 lines long anyway). I don't believe the mod_dbd change has any chance for negative impact and I don't run NetWare. Thanks. -- justin
Re: [vote] 2.2.0 tarballs
Justin Erenkrantz wrote: On Mon, Nov 28, 2005 at 11:55:48PM -0800, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. +1 for GA based on my previous tests with 2.1.10 and a visual inspection of the recursive diff between the 2.1.10 and 2.2.0 tarballs (which is only 314 lines long anyway). Easy way to see the diff: svn diff https://svn.apache.org/repos/asf/httpd/httpd/tags/2.1.10 https://svn.apache.org/repos/asf/httpd/httpd/tags/2.2.0 -Paul
Re: [vote] 2.2.0 tarballs
Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ FWIW, the MIME types for the .md5 files seem to be wrong. The .bz2.md5 is served as application/x-tar and .gz.md5 is application/x-gzip. Luc
Re: [vote] 2.2.0 tarballs
On Tuesday 29 November 2005 08:32, Paul Querna wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: * svn r348009: Added AP_DECLARE to mod_dbd exported functions. No functional changes for most operating systems. Yow! That reminds me: that was in response to someone complaining of a build failure on Windows, and he said it *still* failed with AP_DECLARE. Can someone with Windows *please* look at this? -1 for GA while this is outstanding! http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2 -- Nick Kew
Re: [vote] 2.2.0 tarballs
On Mon, Nov 28, 2005 at 11:55:48PM -0800, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. A quick httpd-test pass on RHEL4/i686 FC3/i686 RHEL3/i686 RHEL3/ppc, plus manual testing, plus diff vs 2.1.10 inspection, +1 for GA. joe
Re: [vote] 2.2.0 tarballs
On 11/29/05, Paul Querna [EMAIL PROTECTED] wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: Shouldn't the final always be equal except version number to the last rc?
Re: [vote] 2.2.0 tarballs
I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. -- Jess Holle Nick Kew wrote: On Tuesday 29 November 2005 08:32, Paul Querna wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: * svn r348009: Added AP_DECLARE to mod_dbd exported functions. No functional changes for most operating systems. Yow! That reminds me: that was in response to someone complaining of a build failure on Windows, and he said it *still* failed with AP_DECLARE. Can someone with Windows *please* look at this? -1 for GA while this is outstanding! http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. mod_dbd isn't included in the win32 build environment yet, so it has no effect on a standard build. mod_dbd may or may not become available within the win32 build environment during the life of 2.2, but I don't think this should hold up GA. It's often the case that some modules or support utilities lag behind on win32. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
problems with ssl in balance/proxy mode
hi everyone
i am new to this list.
since there is no faq available i simple post my request and see what happens.
sorry if i miss any rule.
i have a apache 2.0 in loadbalncing mode using mod_rewrite and mod_proxy.
there have allways been problems with https/ssl requests that where longer than
8192 bytes.
this was because of an erron in ssl_engine_io.c:
ssl_id_filter_input:
snip
/* Create a transient bucket out of the decrypted data. */
if (len 0) {
/* old
apr_bucket *bucket =
apr_bucket_transient_create(inctx-buffer, len, f-c-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(bb, bucket);
*/
apr_brigade_write(bb, NULL, inctx, inctx-buffer, len);
}
return APR_SUCCESS;
/snip
could someone please verify if the code is valid the way i pathed it or if it
is a dirty hack.
also if it is proper code, how do i publish it?
thx a lot
matthias behrens
software development
www.gulp.de
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. mod_dbd isn't included in the win32 build environment yet, so it has no effect on a standard build. mod_dbd may or may not become available within the win32 build environment during the life of 2.2, but I don't think this should hold up GA. It's often the case that some modules or support utilities lag behind on win32. Ah... Sorry to jump the gun. I'm anxious to start the move to 2.2 on various platforms (Windows, Solaris, and AIX). -- Jess Holle
Re: [vote] 2.2.0 tarballs
Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. Steffen - Original Message - From: Colm MacCarthaigh [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Tuesday, November 29, 2005 1:24 PM Subject: Re: [vote] 2.2.0 tarballs On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. mod_dbd isn't included in the win32 build environment yet, so it has no effect on a standard build. mod_dbd may or may not become available within the win32 build environment during the life of 2.2, but I don't think this should hold up GA. It's often the case that some modules or support utilities lag behind on win32. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. +1 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. How are you building these? there's no .dsp file for either, nor are they in Makefile.win. The distributed source tree not building is one thing, but modules people are manually adding is another. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. Why? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
On Tuesday 29 November 2005 12:24, Colm MacCarthaigh wrote: On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. mod_dbd isn't included in the win32 build environment yet, so it has no effect on a standard build. That's another oversight. I can (reluctantly) live with that - though it should go into the release notes, or at least errata. The problem is when someone builds it themselves, and the build dies on them. What signal is that sending? That build, in the hands of someone who knows what he's doing, should NOT fail. Or, if it does, the fact MUST be clearly documented. It's a full week since I noted the issue in http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2 That references the first, and so far only, report I've seen of anyone trying to build it on windows (for values of it encompassing ANY of 2.1.x). For the time being I'll be content with either a definite worksforme or a fails because that can be properly documented. But not with an undocumented situation that apparently leaves users just dangling. -- Nick Kew
Re: [vote] 2.2.0 tarballs
When I see this list then I get the feeling that 2.1/2.2 is not a lot tested on Win32 yet. I build 2.2 on Win32 (without mod_dbd). If you want to test it, you can get the win32 binary from me, please contact me off-list. Also I build some popular modules (mod_security, mod_view, mod_watch, mod_fcgid and mod_log_rotate), see www.apachelounge.com. Steffen - Original Message - From: Nick Kew [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Tuesday, November 29, 2005 2:25 PM Subject: Re: [vote] 2.2.0 tarballs On Tuesday 29 November 2005 12:24, Colm MacCarthaigh wrote: On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. mod_dbd isn't included in the win32 build environment yet, so it has no effect on a standard build. That's another oversight. I can (reluctantly) live with that - though it should go into the release notes, or at least errata. The problem is when someone builds it themselves, and the build dies on them. What signal is that sending? That build, in the hands of someone who knows what he's doing, should NOT fail. Or, if it does, the fact MUST be clearly documented. It's a full week since I noted the issue in http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2 That references the first, and so far only, report I've seen of anyone trying to build it on windows (for values of it encompassing ANY of 2.1.x). For the time being I'll be content with either a definite worksforme or a fails because that can be properly documented. But not with an undocumented situation that apparently leaves users just dangling. -- Nick Kew
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. So it clearly isn't really very critical to anybody, and isn't showstopper material. joe
Re: Various musings about the request URL / URI / whatever
Jim Gallacher writes: Nicolas Lehuen wrote: Second question, if there isn't any simpler way to do this, should we add it to mod_python ? Either as a function like above in mod_python.util, or as a member of the request object (named something like url to match the other member named uri, but that's just teasing). I'm not against it, but for my purposes I think it would be more useful for parsed_uri to just work properly. Here, here!! I've wanted parsed_uri to work as expected for quite some time...I'm actually in a position where I could devote some time to tracking this down. If apache doesn't provide it, I think mod_python should at least fill it in, right? Can someone knudge me in the right direction to start? Haven't poked around apache source and/or developer docs in years. Daniel Popowich --- http://home.comcast.net/~d.popowich/mpservlets/
Re: httpd-2.1.7 Connection-pooling Problem w/ ReverseProxy, Loadbalancer
Can you try HEAD on httpd-trunk for a fix until something more robust as far as the connections are implemented...
Re: [vote] 2.2.0 tarballs
Joe Orton wrote: On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. So it clearly isn't really very critical to anybody, and isn't showstopper material. According to: http://httpd.apache.org/docs/2.1/new_features_2_2.html mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Mike Looijmans wrote: How about we make the first call to get or __getitem__ create the dictionary? We could put code in __getattr__ to create it when it's referenced. For starters, most of the methods such as keys, has_key and so on will raise an exception since you don't create the dictionary until after one of the fields is accessed via __getitem__. Also, has_key will return false for a field that actually exists if that field has not yet been accessed. def hander(req): form = FieldStorage(req) # this will raise an exception keys = form.keys() I still think the correct place to create the index dictionary is in the __init__ phase. Using the dictionary-on-demand idea only improves performance on the second access to a form field. For the first access you are still iterating through the whole list for each field name. I personally think any performance degradation resulting from creating the dictionary in __init__ will be small compared to the overall improvement we'll get for accessing the fields. I would advocate creating the dictionary in the add_field() method. Also, I think you should consistently use add_field in FieldStorage.__init__. In the last line of that method you are still using self.list.append. Seems to me that is a bug waiting to happen. Some future maintainer modifies add_field, missing the list.append and then can't figure out why things are not quite working. Since we are messing with these classes anyway, is there any reason we are not using new-style classes, which is to say subclassing object? Perhaps we should be refactoring our code as we work on mod_python 3.3? Regards, Jim Here is the patch to util.py to use a dictionary-on-demand. Lots of code removed for this one, and a few lines added. There's also a brand new items() function, which, contrary to common belief, preserves argument ordering. Note: This also includes my previous StringField patch, since that is crucial to make the implementation as simple as it is now. Anxiously awaiting your comments and benchmark/profiler results! ['Lies', 'Damn lies', 'Statistics', 'Delivery dates', 'Benchmarks'] Benchmarks will have to wait. I can supply the others any time you want. ;) Jim
Re: [vote] 2.2.0 tarballs
Joe Orton wrote: On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. So it clearly isn't really very critical to anybody, and isn't showstopper material. As I noted in my previous e-mail, I was over-reacting as I did not understand this module was simply not part of the build on Windows yet. Steffan's thoughts may be quite different than mine on this matter, but I'd say go ahead and go for 2.2.0 if this is the biggest issue out there. [I'm much more concerned about authentication against multiple LDAPs than anything else in the authentication arena.] -- Jess Holle
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Just one comment. It seems like it would be better just to make add_method
inline, since everything else in __init__ is, and it never gets called from
anywhere else.
But it looks good and probably fairly optimal. I personally like to see
properties instead of __getattr__ for known attributes, but that's a style
preference.
Nick
Mike Looijmans wrote:
How about we make the first call to get or __getitem__ create the
dictionary? We could put code in __getattr__ to create it when it's
referenced.
Here is the patch to util.py to use a dictionary-on-demand.
Lots of code removed for this one, and a few lines added.
There's also a brand new items() function, which, contrary to common
belief, preserves argument ordering.
Note: This also includes my previous StringField patch, since that is
crucial to make the implementation as simple as it is now.
Anxiously awaiting your comments and benchmark/profiler results!
['Lies', 'Damn lies', 'Statistics', 'Delivery dates', 'Benchmarks']
Index: util.py
===
--- util.py (revision 348746)
+++ util.py (working copy)
@@ -48,19 +48,8 @@
class Field:
- def __init__(self, name, file, ctype, type_options,
-disp, disp_options, headers = {}):
+ def __init__(self, name):
self.name = name
- self.file = file
- self.type = ctype
- self.type_options = type_options
- self.disposition = disp
- self.disposition_options = disp_options
- if disp_options.has_key(filename):
- self.filename = disp_options[filename]
- else:
- self.filename = None
- self.headers = headers
def __repr__(self):
Return printable representation.
@@ -81,13 +70,34 @@
self.file.close()
class StringField(str):
-This class is basically a string with
- a value attribute for compatibility with std lib cgi.py
-
+ This class is basically a string with
+added attributes for compatibility with std lib cgi.py. Basically, this
+works the opposite of Field, as it stores its data in a string, but creates
+a file on demand. Field creates a value on demand and stores data in a
file.
+
+filename = None
+headers = {}
+ctype = text/plain
+type_options = {}
+disposition = None
+disp_options = None
+
+# I wanted __init__(name, value) but that does not work (apparently, you
+# cannot subclass str with a constructor that takes 1 argument)
+def __init__(self, value):
+'''Create StringField instance. You'll have to set name yourself.'''
+str.__init__(self, value)
+self.value = value
- def __init__(self, str=):
- str.__init__(self, str)
- self.value = self.__str__()
+def __getattr__(self, name):
+if name != 'file':
+raise AttributeError, name
+self.file = cStringIO.StringIO(self.value)
+return self.file
+
+def __repr__(self):
+ Return printable representation (to pass unit tests).
+ return Field(%s, %s) % (`self.name`, `self.value`)
class FieldStorage:
@@ -103,8 +113,7 @@
if req.args:
pairs = parse_qsl(req.args, keep_blank_values)
for pair in pairs:
- file = cStringIO.StringIO(pair[1])
- self.list.append(Field(pair[0], file, text/plain, {}, None,
{}))
+ self.add_field(pair[0], pair[1])
if req.method != POST:
return
@@ -123,9 +132,7 @@
if ctype.startswith(application/x-www-form-urlencoded):
pairs = parse_qsl(req.read(clen), keep_blank_values)
for pair in pairs:
- # TODO : isn't this a bit heavyweight just for form fields ?
- file = cStringIO.StringIO(pair[1])
- self.list.append(Field(pair[0], file, text/plain, {}, None,
{}))
+ self.add_field(pair[0], pair[1])
return
if not ctype.startswith(multipart/):
@@ -205,33 +212,44 @@
else:
name = None
+ # create a file object
# is this a file?
if disp_options.has_key(filename):
if file_callback and callable(file_callback):
file = file_callback(disp_options[filename])
else:
- file = self.make_file()
+ file = tempfile.TemporaryFile(w+b)
else:
if field_callback and callable(field_callback):
file = field_callback()
else:
- file = self.make_field()
+ file = cStringIO.StringIO()
# read it in
- end_of_stream = self.read_to_boundary(req, boundary, file)
+ self.read_to_boundary(req, boundary, file)
file.seek(0)
-
+
# make a Field
Re: [vote] 2.2.0 tarballs
Jim Jagielski wrote: Joe Orton wrote: On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. So it clearly isn't really very critical to anybody, and isn't showstopper material. According to: http://httpd.apache.org/docs/2.1/new_features_2_2.html mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. That is a good point. Truth in advertising (as best as can be managed) will only help -- and lack thereof only hurt... -- Jess Holle
Re: [vote] 2.2.0 tarballs
On Tuesday 29 November 2005 15:03, Joe Orton wrote: On Tue, Nov 29, 2005 at 02:03:59PM +0100, Steffen wrote: Build with no issue here on Windows, except mod_authn_db and dmod_dbd. In the change log: *) Add mod_authn_dbd (SQL-based authentication) [Nick Kew] I agree with Jesse: 2.2.0 should not go out the door until we can build mod_authn_db and mod_dbd on windows. It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. It works nicely on platforms I use. But last week was the first report of anyone building it on windows. Or rather, trying and failing to build it. I'd guess that's precisely because it's now stable for us as devs, a slightly wider circle of testers are looking at it. That's a Good Thing. When it goes GA, we can expect a *much* wider range of users, and they'll be less tolerant of things not working. I don't even know if it's a bug or a user error. If it is a bug, it would obviously be best to fix it, but an acceptable second-best is to document it. As for suddenly waking up, please note the date on http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2 -- Nick Kew
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 10:16:04AM -0500, Jim Jagielski wrote: mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! It can wait until the next release of 2.2. We can note it in the release notes and move along. -- justin
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Jim Gallacher wrote: For starters, most of the methods such as keys, has_key and so on will raise an exception since you don't create the dictionary until after one of the fields is accessed via __getitem__. Also, has_key will return false for a field that actually exists if that field has not yet been accessed. Since __getitem__ refers to self.dictionary, it would get created at that point. I don't think that's an issue. def hander(req): form = FieldStorage(req) # this will raise an exception keys = form.keys() I still think the correct place to create the index dictionary is in the __init__ phase. Using the dictionary-on-demand idea only improves performance on the second access to a form field. For the first access you are still iterating through the whole list for each field name. Isn't that what on-demand means? If you never use the dictionary, you'll never have to wait for it to be created. This is at worst no worse than what is there now (actually it's better the way he's coded it). I personally think any performance degradation resulting from creating the dictionary in __init__ will be small compared to the overall improvement we'll get for accessing the fields. I would advocate creating the dictionary in the add_field() method. Depends on the size of the form, but I can see a performance hit for people (like me) who never use FieldStorage as a dictionary. Since we are messing with these classes anyway, is there any reason we are not using new-style classes, which is to say subclassing object? Isn't that the default in 2.3+, which is what mod_python now requires? Nick
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Nick wrote: Just one comment. It seems like it would be better just to make add_method inline, since everything else in __init__ is, and it never gets called from anywhere else. add_method? But it looks good and probably fairly optimal. I personally like to see properties instead of __getattr__ for known attributes, but that's a style preference. I also like properties, but doesn't that cause a problem if someone chooses to subclass FieldStorage? Jim Nick Mike Looijmans wrote: How about we make the first call to get or __getitem__ create the dictionary? We could put code in __getattr__ to create it when it's referenced. Here is the patch to util.py to use a dictionary-on-demand. Lots of code removed for this one, and a few lines added. There's also a brand new items() function, which, contrary to common belief, preserves argument ordering. Note: This also includes my previous StringField patch, since that is crucial to make the implementation as simple as it is now. Anxiously awaiting your comments and benchmark/profiler results! ['Lies', 'Damn lies', 'Statistics', 'Delivery dates', 'Benchmarks']
Re: [vote] 2.2.0 tarballs
Justin Erenkrantz wrote: On Tue, Nov 29, 2005 at 10:16:04AM -0500, Jim Jagielski wrote: mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! It can wait until the next release of 2.2. We can note it in the release notes and move along. -- justin I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is one platform among many that we support. Additionally, we have very few developers who care to maintain Win32. mod_dbd apparently works just fine on every other platform. Therefore, I don't think removing it from the feature list is warranted. If no one cared about it until now, I don't care about it either. If mod_dbd didn't work on Darwin, I wouldn't ask that we remove it from the features list if it works on Linux, Solaris, and Win32. I'd ask that it be noted and move along. I don't know why we would or should grant special consideration to Win32 here. -- justin
Re: [vote] 2.2.0 tarballs
On 11/29/05, Justin Erenkrantz [EMAIL PROTECTED] wrote: On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is one platform among many that we support. Additionally, we have very few developers who care to maintain Win32. mod_dbd apparently works just fine on every other platform. Therefore, I don't think removing it from the feature list is warranted. If no one cared about it until now, I don't care about it either. If mod_dbd didn't work on Darwin, I wouldn't ask that we remove it from the features list if it works on Linux, Solaris, and Win32. I'd ask that it be noted and move along. I don't know why we would or should grant special consideration to Win32 here. -- justin Why not add a special 'except on Windows' clause to that page?
Re: [vote] 2.2.0 tarballs
On Nov 29, 2005, at 2:55 AM, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. Passes tests: +1 for GA.
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: Justin Erenkrantz wrote: On Tue, Nov 29, 2005 at 10:16:04AM -0500, Jim Jagielski wrote: mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! It can wait until the next release of 2.2. We can note it in the release notes and move along. -- justin I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. joe
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 04:38:01PM +0100, Olaf van der Spek wrote: Why not add a special 'except on Windows' clause to that page? It's not like it'll never work. Someone will get around to fixing it. IMHO, this is exactly what release notes are for. -- justin
Re: [vote] 2.2.0 tarballs
On Tuesday 29 November 2005 15:22, Justin Erenkrantz wrote: We can note it in the release notes and move along. -- justin Indeed, that's fine by me. I've just committed a documentation update to Trunk. If we backport that to branch-2.2, I'll withdraw my objections. -- Nick Kew
Re: [vote] 2.2.0 tarballs
The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! I cared, when I recall mod_dbd was compiling with a former apr (pity I do not know which version) For me is a reason to upgrade is mod_authn_db (which relies on mod_dbd) . When you guys go on with 2.2 then add also a note to mod_authn_db docu that it is not available on win32. Steffen - Original Message - From: Justin Erenkrantz [EMAIL PROTECTED] To: dev@httpd.apache.org; [EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:22 PM Subject: Re: [vote] 2.2.0 tarballs On Tue, Nov 29, 2005 at 10:16:04AM -0500, Jim Jagielski wrote: mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! It can wait until the next release of 2.2. We can note it in the release notes and move along. -- justin
Re: [vote] 2.2.0 tarballs
On Nov 29, 2005, at 10:36 AM, Justin Erenkrantz wrote: On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is one platform among many that we support. Additionally, we have very few developers who care to maintain Win32. mod_dbd apparently works just fine on every other platform. Therefore, I don't think removing it from the feature list is warranted. If no one cared about it until now, I don't care about it either. If mod_dbd didn't work on Darwin, I wouldn't ask that we remove it from the features list if it works on Linux, Solaris, and Win32. I'd ask that it be noted and move along. I don't know why we would or should grant special consideration to Win32 here. -- justin Either we: 1. Remove it from the feature list 2. Keep it in there, but document that it doesn't build under Win32 3. Someone who knows Win32 adds whatever magic is required to have it build. I don't care which one is done, but doing none is just plain sloppy, and we're better than that (or, at least, we *should* be).
Re: [vote] 2.2.0 tarballs
Joe Orton wrote: On Tue, Nov 29, 2005 at 10:28:43AM -0500, Jim Jagielski wrote: Justin Erenkrantz wrote: On Tue, Nov 29, 2005 at 10:16:04AM -0500, Jim Jagielski wrote: mod_dbd is explicitly mentioned as a new feature of 2.2 and, therefore, a compelling reason to upgrade. Either we stop refering to mod_dbd as something special enough to warrant special attention as a core enhancement or we fix it so it *is* one. The fact that no one has ever cared to make mod_dbd work on Windows until the precise instance that we're to go to GA is complete evidence that this is not a showstopper. It's not even in the default build! It can wait until the next release of 2.2. We can note it in the release notes and move along. -- justin I would agree, as long as we remove it for the What's New pages until it actually works and builds. My point, obviously, was that we can't have it both ways and say mod_dbd is great and a new core enhancement if it doesn't even build under Win32. Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. Now *that's* a statement for the Release Notes :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 10:46:55AM -0500, Jim Jagielski wrote: Either we: 1. Remove it from the feature list 2. Keep it in there, but document that it doesn't build under Win32 3. Someone who knows Win32 adds whatever magic is required to have it build. #2 would be in the release notes. I don't think anyone has said we wouldn't note it. If someone figures out the necessary bits to twiddle by the time we make an announcement, we can stick it in the 'patches_to_apply' directory too. But, removing it from the feature list because it doesn't work on one platform out of many doesn't sit well with me. (And, it's not even in the default build for that platform anyway!) -- justin
Re: [vote] 2.2.0 tarballs
Justin Erenkrantz wrote: On Tue, Nov 29, 2005 at 10:46:55AM -0500, Jim Jagielski wrote: Either we: 1. Remove it from the feature list 2. Keep it in there, but document that it doesn't build under Win32 3. Someone who knows Win32 adds whatever magic is required to have it build. #2 would be in the release notes. I don't think anyone has said we wouldn't note it. That wasn't clear at the start of this thread. There was a tone of I don't care, that's no reason to stop the release and the impression that nothing would be done to address it. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: Various musings about the request URL / URI / whatever
2005/11/29, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]:
On Tue, 29 Nov 2005, Nicolas Lehuen wrote: def current_url(req):[snip]# hostcurrent_url.append(req.hostname)[snip]This part isn't going to work reliably if you are not using virtual hosts
and just bind to an IP number. Deciphering the URL is an impossible task -I used to have similar code in my apllications, but lately I realized thatit does not work reliably and it is much simpler to just treat it as a
configuration item...
That's awful. How come such a basic thing is so difficult ? I mean,
isn't it weird that server-side code has less information about its URL
than the client ? Note that it's not a mod_python specific problem,
I've seen it also in the Servlet API.
If I understand you correctly, req.hostname is not reliable in case where virtual hosting is not used. What about server.server_hostname, which seems to be used by the code from mod_rewrite you posted below ? Can it be used reliably ?
First question, is there a simpler way to do this ? Ironically, when using mod_rewrite, you get an environment variable named SCRIPT_URI which is
precisely what I need (SCRIPT_URL, also added by mod_rewrite, is equivalent to req.uri... Don't ask we why). But relying on it isn't safe since mod_rewrite isn't always used.well - here's how it does it.
/**create the SCRIPT_URI variable for the env*/ /* add the canonical URI of this URL */ thisserver = ap_get_server_name(r); port = ap_get_server_port(r); if (ap_is_default_port(port, r)) {
thisport = ; } else { apr_snprintf(buf, sizeof(buf), :%u, port); thisport = buf; } thisurl = apr_table_get(r-subprocess_env, ENVVAR_SCRIPT_URL);
/* set the variable */ var = apr_pstrcat(r-pool, ap_http_method(r), ://, thisserver, thisport,thisurl,
NULL); apr_table_setn(r-subprocess_env, ENVVAR_SCRIPT_URI, var); /* if filename was not initially set,* we start with the requested URI*/ if (r-filename == NULL) {
r-filename = apr_pstrdup(r-pool, r-uri); rewritelog(r, 2, init rewrite engine with requested uri %s,r-filename); }
Shall we add this code to the native part of the request object, then ?
Or the server object (without the URL part), maybe ? But is it really
reliable (see question above) ?
Second question, if there isn't any simpler way to do this, should we add it
to mod_python ? Either as a function like above in mod_python.util, or as a member of the request object (named something like url to match the other member named uri, but that's just teasing).
I don't know... Since the result is going to be half-baked... I think amore interesting and mod_python-ish thing to do would be to expose all theAPI's used in the above code (e.g. ap_get_server_name, ap_is_default_port,
ap_http_method) FIRST, then think about this. And third question (in pure Spanish inquisition style) : why is req.parsed_uri returning me a tuple full of Nones except for the uri and path_info part ?
This is an httpd question most likely...
So it's a feature / bug in httpd. Maybe it's due to my use of VirtualDocumentRoot.
Ah, fourth question : why are we (mod_python, mod_rewrite and the CGI environment variables) using the terms URI and URL to distinguish
between a full, absolute resource path and a path relative to the server, whereas the definition of URLs and URIs is very vague and nothing close to this (
http://www.w3.org/TR/uri-clarification/#contemporary) ? Shouldn't we save our souls and a lot of saliva by choosing better names ?No, we (mod_python) should just use the exact same name that httpd uses.
If we come up better names, then it's just going to make it even moreconfusing.
Fair enough. The problem is that even httpd and mod_rewrite don't agree on what an URL and an URI are...
OK, OK, fifth question : we made req.filename and other members writable. But when those attributes are changed, as Graham noted a while ago, the
other dependent ones aren't, leading to inconsitencies (for example, if you change req.filename, req.canonical_filename isn't changed). Should we try to solve thisThe solutions is to make
req.canonical_filename writable too and documentthat if you change req.filename, you may consider changingcanonical_filename as well and what will happen if you do not. and provide clear definition of the various parts of a request
for mod_python 3.3 ?Yes, that'd be good :)Grisha
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 10:56:56AM -0500, Jim Jagielski wrote: #2 would be in the release notes. I don't think anyone has said we wouldn't note it. That wasn't clear at the start of this thread. There was a tone of I don't care, that's no reason to stop the release and the impression that nothing would be done to address it. Well, that's just silly. If you read my replies about this, in almost every one, I said something about including it in the release notes and moving on. I'm sure no one really meant that we wouldn't make some mention of it in the appropriate places given that we now know about it. -- justin
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 03:20:50PM +, Nick Kew wrote: As for suddenly waking up, please note the date on http://marc.theaimsgroup.com/?l=apache-httpd-devm=113266737311013w=2 mod_dbd compiles fine for me when I remove the AP_DECLARE wrappers actually. But that might break the symbol export on Windows, I don't know. Doing a mod_cache/ldap-like workaround where a BDB_DECLARE maps to an _EXPORT macro is probably something that would make it work too. How do can I test mod_dbd to find out if my changes are commitable? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Nick wrote: Jim Gallacher wrote: For starters, most of the methods such as keys, has_key and so on will raise an exception since you don't create the dictionary until after one of the fields is accessed via __getitem__. Also, has_key will return false for a field that actually exists if that field has not yet been accessed. Since __getitem__ refers to self.dictionary, it would get created at that point. I don't think that's an issue. Oops. Brain fart. When I read the code I s/__getattr__/__getitem__/g. def hander(req): form = FieldStorage(req) # this will raise an exception keys = form.keys() I still think the correct place to create the index dictionary is in the __init__ phase. Using the dictionary-on-demand idea only improves performance on the second access to a form field. For the first access you are still iterating through the whole list for each field name. Isn't that what on-demand means? If you never use the dictionary, you'll never have to wait for it to be created. This is at worst no worse than what is there now (actually it's better the way he's coded it). You are correct, there is no problem. It works as advertised. Operator error... whoot, whoot, whoot. :) I personally think any performance degradation resulting from creating the dictionary in __init__ will be small compared to the overall improvement we'll get for accessing the fields. I would advocate creating the dictionary in the add_field() method. Depends on the size of the form, but I can see a performance hit for people (like me) who never use FieldStorage as a dictionary. Just curious. How do you use it? Since we are messing with these classes anyway, is there any reason we are not using new-style classes, which is to say subclassing object? Isn't that the default in 2.3+, which is what mod_python now requires? Exactly. I guess my question would be is there any reason to *not* refactor our code? Jim
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Nick wrote: Jim Gallacher wrote: Nick wrote: Just one comment. It seems like it would be better just to make add_method inline, since everything else in __init__ is, and it never gets called from anywhere else. add_method? Haha, thanks, I haven't had coffee yet. The add_item method, that is. :) By which I assume you mean add_field? Other than that you are perfectly all right. :) I also like properties, but doesn't that cause a problem if someone chooses to subclass FieldStorage? It could if you didn't realize it was a property. But you can always override a property with another property. I've only started using properites and I hadn't thought of that. If we were to use such a feature is that the sort detail that would be included in the user documentation, or would the coder just be expected to read the source? Jim
Re: Various musings about the request URL / URI / whatever
On Tue, 29 Nov 2005, Nicolas Lehuen wrote: If I understand you correctly, req.hostname is not reliable in case where virtual hosting is not used. What about server.server_hostname, which seems to be used by the code from mod_rewrite you posted below ? Can it be used reliably ? I don't think so. if I do this: telnet some.host.com 80 GET /index.html How would apache know what the hostname is? Grisha
Re: Various musings about the request URL / URI / whatever
On Tue, 29 Nov 2005, Nicolas Lehuen wrote: 2005/11/29, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]: Shall we add this code to the native part of the request object, then ? Or the server object (without the URL part), maybe ? No, I wasn't suggesting that by any means :-) The point was to demostrate that mod_rewrite does pretty much the same excercise your Python code was doing, there is no magic there. What I did suggest was: I think a more interesting and mod_python-ish thing to do would be to expose all the API's used in the above code (e.g. ap_get_server_name, ap_is_default_port, ap_http_method) FIRST, then think about this. Grisha
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Gregory (Grisha) Trubetskoy wrote: On Tue, 29 Nov 2005, Jim Gallacher wrote: I still think the correct place to create the index dictionary is in the __init__ phase. Using the dictionary-on-demand idea only improves performance on the second access to a form field. For the first access you are still iterating through the whole list for each field name. I am still not convinced we need an index. I'd like to see some concrete proof that we're not engaging in overoptimization here - is this really a bottleneck for anyone? Well, I need to get some real work done today, but I will do some benchmarking at some point. It's not like there's a big rush to complete 3.3.0 this week. I do like that Mike's code simplifies a number of the the FS methods. It just looks more elegant. If we're concerned (and I'm not at this point) that FieldStorage is too slow, we should just rewrite the whole thing in C :-) A worthy goal. Perhaps we should re-write all of mod_python in C Any takers? No? Maybe not then. :) Jim
Re: [vote] 2.2.0 tarballs
Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. And how many people compile the thing on Windows anyway, except the msi builder? My guess is that I need about 2 hands to count them Joost
Re: Various musings about the request URL / URI / whatever
Gregory (Grisha) Trubetskoy wrote: What I did suggest was: I think a more interesting and mod_python-ish thing to do would be to expose all the API's used in the above code (e.g. ap_get_server_name, ap_is_default_port, ap_http_method) FIRST, then think about this. +1. I think it would be much more Pythonic (and much more maintainable) to have the _apache module only provide a nearly transparent access to the apache API, then have the actual apache.py wrap everything. The way it is now it's kind of half and half. Only really CPU intensive stuff should be in the C code (is there really anything like that?). Also, you give others the opportunity to implement their own wrappers instead of using those in apache.py, if they so desire. Nick
Re: [vote] 2.2.0 tarballs
I didn't expect the NetWare fixes to go in until 2.2.1. Thanks for including them. +1 GA (NetWare) Brad On 11/29/2005 at 1:32:32 am, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: * svn r348009: Added AP_DECLARE to mod_dbd exported functions. No functional changes for most operating systems. * svn r348055 and 348029: Netware specific fixes for a missing SSL CGI variable, and for linking to the correct sockets library. * Several Documentation only commits. (Including updating URLs in the README, UPDATING, etc..) -Paul
Re: [vote] 2.2.0 tarballs
We don't until the first GA release, but from there on out we compile just about every release ourselves as we often end up applying our own patches when we find issues (submitting them back, of course) and we do our own cross-platform installation packaging, automated configuration, etc, of Apache for our customers (so the raw build result is more useful). -- Jess Holle Joost de Heer wrote: Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. And how many people compile the thing on Windows anyway, except the msi builder? My guess is that I need about 2 hands to count them Joost
Re: svn commit: r349752 - in /httpd/httpd/trunk/modules/database: mod_dbd.c mod_dbd.h
On Tuesday 29 November 2005 16:37, [EMAIL PROTECTED] wrote: -AP_DECLARE(void) ap_dbd_prepare(server_rec *s, const char *query, +DBD_DECLARE(void) ap_dbd_prepare(server_rec *s, const char *query, const char *label) OK, other modules do this. Yet the #defines for DBD_DECLARE et al are identical to AP_DECLARE, aren't they? What is supposed to be the purpose of namespacing different modules? -- Nick Kew
Re: svn commit: r349752 - in /httpd/httpd/trunk/modules/database: mod_dbd.c mod_dbd.h
On Tue, Nov 29, 2005 at 05:25:31PM +, Nick Kew wrote: On Tuesday 29 November 2005 16:37, [EMAIL PROTECTED] wrote: -AP_DECLARE(void) ap_dbd_prepare(server_rec *s, const char *query, +DBD_DECLARE(void) ap_dbd_prepare(server_rec *s, const char *query, const char *label) OK, other modules do this. Yet the #defines for DBD_DECLARE et al are identical to AP_DECLARE, aren't they? What is supposed to be the purpose of namespacing different modules? In mod_dbd.dsp we can now have /D DBD_DECLARE_EXPORT which means we use dllexport, not dllimport without over-riding other AP_DECLARE's :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
Paul Querna wrote: Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Okay, I lied, slightly: * svn r348009: Added AP_DECLARE to mod_dbd exported functions. No functional changes for most operating systems. * svn r348055 and 348029: Netware specific fixes for a missing SSL CGI variable, and for linking to the correct sockets library. * Several Documentation only commits. (Including updating URLs in the README, UPDATING, etc..) My vote, +1 for GA, tested lightly on FreeBSD 5.4/x86, and OSX 10.4.3/ppc. Also based on diff of the 2.1.10 and 2.2.0 tarballs. -Pau
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 09:30:30AM -0800, Paul Querna wrote: My vote, +1 for GA, tested lightly on FreeBSD 5.4/x86, and OSX 10.4.3/ppc. Also based on diff of the 2.1.10 and 2.2.0 tarballs. +1 here too, tested on ubuntu. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Nick wrote: Jim Gallacher wrote: I've only started using properites and I hadn't thought of that. If we were to use such a feature is that the sort detail that would be included in the user documentation, or would the coder just be expected to read the source? You CAN read the source if you need implementation details, especially if you're going to override the default behavior. However, in most cases I think you're going to extend behavior, so you will eventually call the superclass' getter/setter. A real problem with Python is that there's no standard convention for writing property getters and setters. I myself use an idiom like this: def variable(): def fget(self): return None def fset(self, value): pass def fdel(self): pass doc = The documentation return locals() variable = property(**variable()) I like this idiom, because it's really easy to spot in the code, and it keeps everything together for the property. This forces you to completely override the property in a subclass, but you don't have to know the implementation details of the superclass to do that. Cool. Another way might be (minimally and traditionally): def variable_getter(self): return None def variable_setter(self): pass variable = property(variable_getter, variable_setter) which then allows you to override variable_getter or variable_setter in your subclass without overriding the property itself, but now you've got to read the code. Or else completely override the property, but you've got a choice. My understanding (confired via experimentation) is that with the 'traditional' way you can't orerride the getter or setter originally bound in by property call. The original methods will be used, not the ones in the subclass. class Stuff(object): def getA(self): return 'stuff' a = property(getA) class MoreStuff(object): def getA(self): return 'MORE stuff' thing = MoreStuff() print thing.a stuff But at any rate, these are basic python questions and I don't think python-dev is the correct forum for this discussion. Thanks for giving me a couple of ideas to try out Nick. Regards, Jim
Re: [vote] 2.2.0 tarballs
On Tue, Nov 29, 2005 at 05:53:52AM -0600, Jess Holle wrote: I'm no commiter but must concur -- until the build runs cleanly on Windows 2.2.0 should not go out the door. Not everyone may like it, but Windows is a major Apache usage platform these days. O.k., can any win32 users please test the mod_dbd and mod_authn_dbd build environments that are now in trunk? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
OT: performance FUD
This is probably way off topic for this list. I was searching for something related to php this morning (I know, I know... But some people here need php) and the majority of the google hits where FUD sites. Most of them generally say Apache is bloated and slow, you should use X. I know we have several people on this list who run Apache on very high traffic sites. While we cannot answer every single piece of FUD out there, do we need a general page to answer some of them. Maybe testimonials or something. I know, with my config, I can easily saturate multiple gig interfaces and have a rather full feature installation. Thoughts? -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: OT: performance FUD
--On November 29, 2005 2:50:19 PM -0500 Brian Akins [EMAIL PROTECTED] wrote: This is probably way off topic for this list. I was searching for something related to php this morning (I know, I know... But some people here need php) and the majority of the google hits where FUD sites. Most of them generally say Apache is bloated and slow, you should use X. I know we have several people on this list who run Apache on very high traffic sites. While we cannot answer every single piece of FUD out there, do we need a general page to answer some of them. Maybe testimonials or something. I know, with my config, I can easily saturate multiple gig interfaces and have a rather full feature installation. Thoughts? First off, this is absolutely on-topic for this list. =) Most high-traffic sites keep their details under wraps. If you are willing to have some information made public (i.e. how much traffic you do, how many servers, etc.), I'm sure we could post a page on our website towards that end. I've presented some talks about how apache.org runs httpd with one small httpd instance. It'd be nice to complement that information with other sites who have far more complicated setups. -- justin
Re: OT: performance FUD
Justin Erenkrantz wrote: Most high-traffic sites keep their details under wraps. If you are willing to have some information made public (i.e. how much traffic you do, how many servers, etc.), I'm sure we could post a page on our website towards that end. Would this be a worthwhile ApacheCon topic? (I'm already angling to get a speakers spot for next year.) We do some interesting things here :) For the time being, for a web page, I could discuss some performance metrics we use. The amount of traffic we get is basically public knowledge (we have press releases from time to time). I'm sure I could talk/write in generalities, but not we use X servers. But I can certainly report some general benchmark numbers. Does that make any sense? -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: OT: performance FUD
Justin Erenkrantz wrote: It'd be nice to complement that information with other sites who have far more complicated setups. -- justin This could also be part of a press release announcing 2.2. Just between Brian and Colm we could have a couple impressive-sounding quotes. Joshua.
Re: OT: performance FUD
--On November 29, 2005 3:16:43 PM -0500 Joshua Slive [EMAIL PROTECTED] wrote: This could also be part of a press release announcing 2.2. Just between Brian and Colm we could have a couple impressive-sounding quotes. Agreed. If they're up for being quoted, they'd be great. -- justin
Re: OT: performance FUD
Joshua Slive wrote: This could also be part of a press release announcing 2.2. Just between Brian and Colm we could have a couple impressive-sounding quotes. I know that a press release is out of the question for my company. We do not endorse or disparage any product. We could be referred to as one large company or something similar... It's not that hard to figure out what we run.. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: OT: performance FUD
On Tue, Nov 29, 2005 at 03:16:43PM -0500, Joshua Slive wrote: This could also be part of a press release announcing 2.2. Just between Brian and Colm we could have a couple impressive-sounding quotes. +1 great idea! Making it known that the 2.2GA has been stress tested at high profile sites for quite a while is likely to help along 2.2 adoption. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: OT: performance FUD
--On November 29, 2005 3:15:05 PM -0500 Brian Akins [EMAIL PROTECTED] wrote: Would this be a worthwhile ApacheCon topic? (I'm already angling to get a speakers spot for next year.) We do some interesting things here :) For Absolutely. the time being, for a web page, I could discuss some performance metrics we use. The amount of traffic we get is basically public knowledge (we have press releases from time to time). I'm sure I could talk/write in generalities, but not we use X servers. But I can certainly report some general benchmark numbers. Does that make any sense? Sure. FWIW, most people only care about generalities not any specifics. We don't need to have specifics. Stuff like Just under 1 billion requests here is spot-on. =) -- justin
Re: OT: performance FUD
Justin Erenkrantz wrote: Sure. FWIW, most people only care about generalities not any specifics. We don't need to have specifics. Stuff like Just under 1 billion requests here is spot-on. =) -- justin Cool. I have asked my SVP what is acceptable for me to say. But it doesn't take a rocket scientist to figure it out: http://toolbar.netcraft.com/site_report?url=http://www.cnn.com plus http://www.lostremote.com/archives/002933.html -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: OT: performance FUD
Brian Akins wrote: This is probably way off topic for this list. I was searching for something related to php this morning (I know, I know... But some people here need php) and the majority of the google hits where FUD sites. Most of them generally say Apache is bloated and slow, you should use X. I know we have several people on this list who run Apache on very high traffic sites. While we cannot answer every single piece of FUD out there, do we need a general page to answer some of them. Maybe testimonials or something. I know, with my config, I can easily saturate multiple gig interfaces and have a rather full feature installation. Apache isn't the fastest web server -- at least without mod_event. I've seen data corruption with all of the free single-process web servers, although I'd assume that products like Zeus do better. Looking at Alexa, the logs from a few sites I run, and benchmarking I've done, there are probably only a few thousand web sites in the world that push the limits of a single Apache web server. Perhaps 100x as many PHB's ~might~ pick a web server because of numbers in a glossy ad. The real competition is with IIS, and people don't choose Apache or IIS based on performance numbers -- they choose it because they are familiar with Unix or familiar with Windows. Other web servers are at the 1% market share level: http://news.netcraft.com/archives/2005/11/07/november_2005_web_server_survey.html Don't make it a fudbusting site, make it a apache performance tuning site. There are all of these statements in the apache docs that * .htaccess is slow * ExtendedStatus on reduces performance We did a round of performance testing on a server that we commissioned last year and took measurements of these things, and found that we'd need to put 1000 rewriting rules to harm performance noticably, that the overhead of ExtendedStatus On is negligible for a site that gets 500 hits/sec, etc. I might see if I can find my report about this on this and put it online -- there some things that I know, and even more that I don't... * prefork and worker seem to be about equally fast on linux? * is the case on Solaris? * MacOS X? * Solaris 9 is embarassingly slow running Apache compared to Linux -- is the same the case with Solaris 10?
Re: OT: performance FUD
--On November 29, 2005 3:40:11 PM -0500 Paul A Houle [EMAIL PROTECTED] wrote: * prefork and worker seem to be about equally fast on linux? Yup - this is because forking and threading are equivalent (by and large) on Linux. * is the case on Solaris? No. The threading gains of worker are seen with Solaris and, I believe, AIX. * MacOS X? I haven't done a lot of high-end sites on Mac OS X. * Solaris 9 is embarassingly slow running Apache compared to Linux -- is the same the case with Solaris 10? If it's on equivalent hardware (i.e. Linux/Intel vs. Solaris/Intel on the same box), I doubt there will be an extreme performance gap. In fact, I've often seen Solaris outperform Linux on certain types of loads. In my experience, a lot of Linux network card drivers are sub-standard; if it's supported by Solaris, there's a fair chance the driver takes full advantage of the hardware. (Netgear GigE drivers on Linux are abysmal.) -- justin
Re: OT: performance FUD
Paul A Houle wrote: Don't make it a fudbusting site, make it a apache performance tuning site. There are all of these statements in the apache docs that * .htaccess is slow * ExtendedStatus on reduces performance We did a round of performance testing on a server that we commissioned last year and took measurements of these things, and found that we'd need to put 1000 rewriting rules to harm performance noticably, that the overhead of ExtendedStatus On is negligible for a site that gets 500 hits/sec, etc. I might see if I can find my report about this on this and put it online -- there some things that I know, and even more that I don't... * prefork and worker seem to be about equally fast on linux? * is the case on Solaris? * MacOS X? * Solaris 9 is embarassingly slow running Apache compared to Linux -- is the same the case with Solaris 10? Suggestions to improve http://httpd.apache.org/docs/2.1/misc/perf-tuning.html are very welcome. Suggestions backed by data are even better. One issue is that this page was written for (and, in fact, by) the Dean Gaudet-type performance freak who was looking to squeeze every last ounce of performance when serving static pages. All you need to do is add one CGI script or php app to your site and everything on that page after the hardware section gets lost in the noise. So when people mail [EMAIL PROTECTED] asking how to fix performance problems, the answer is almost always fix your database or rewrite your web app and not change your apache configuration or get a faster web server. That is why just communicating the fact that apache is fast enough in almost all cases is important. Joshua.
Re: OT: performance FUD
Joshua Slive wrote: Suggestions to improve http://httpd.apache.org/docs/2.1/misc/perf-tuning.html are very welcome. Suggestions backed by data are even better. Basically there's nothing quantitative there. There's a lot of talk about some operating systems and not a lot of talk about specifics. One issue is that this page was written for (and, in fact, by) the Dean Gaudet-type performance freak who was looking to squeeze every last ounce of performance when serving static pages. All you need to do is add one CGI script or php app to your site and everything on that page after the hardware section gets lost in the noise. So when people mail [EMAIL PROTECTED] asking how to fix performance problems, the answer is almost always fix your database or rewrite your web app and not change your apache configuration or get a faster web server. For me, that's the reason why quantitative information is so important. I did extensive performance testing on the new server we commissioned precisely because of the situation you describe: we had people saying rewriting is slow, extendedstatus on is slow -- people were making decisions based on qualitative statements about performance, not qualitative performance. After doing those tests, I learned that I had nothing to fear if I wanted to put in 500 rewriting rules, but that 50,000 is too much.
Re: OT: performance FUD
Justin Erenkrantz wrote: If it's on equivalent hardware (i.e. Linux/Intel vs. Solaris/Intel on the same box), I doubt there will be an extreme performance gap. In fact, I've often seen Solaris outperform Linux on certain types of loads. In my experience, a lot of Linux network card drivers are sub-standard; if it's supported by Solaris, there's a fair chance the driver takes full advantage of the hardware. (Netgear GigE drivers on Linux are abysmal.) -- justin I think the issue with Apache/Solaris is that process switches take a long time on Solaris. I've got a computer that I need to rehabilitate for the family this Christmas. I think I'll put Solaris 10 on it and do some web server benching before I put Ubuntu on it.
Re: OT: performance FUD
On Tuesday 29 November 2005 20:49, Justin Erenkrantz wrote: --On November 29, 2005 3:40:11 PM -0500 Paul A Houle [EMAIL PROTECTED] wrote: * prefork and worker seem to be about equally fast on linux? Yup - this is because forking and threading are equivalent (by and large) on Linux. That's the conventional wisdom for static stuff. If DBD catches on it'll change. In my experience, a lot of Linux network card drivers are sub-standard; if it's supported by Solaris, there's a fair chance the driver takes full advantage of the hardware. (Netgear GigE drivers on Linux are abysmal.) -- justin Is that why Linux server (as opposed to desktop) hardware tends to standardise on a few well-supported brand such as 3Com and Intel? I have 3Com on the server and something much cheaper on the desktop:-) And I discovered the hard way that SCSI discs are still a Good Idea if they're doing something nontrivial in the server. -- Nick Kew
Re: OT: performance FUD
On Tue, Nov 29, 2005 at 03:18:57PM -0500, Brian Akins wrote: I know that a press release is out of the question for my company. We do not endorse or disparage any product. That's understandable, for a news organisation. For our part, HEAnet has no problem being quoted, but maybe something like; Apache httpd 2.2 has been developed with community involvement and has been deployed and tested on some of the most active websites on the internet, and has handled billions of requests in production environments. We could be referred to as one large company or something similar... It's not that hard to figure out what we run.. It's public knowledge that CNN.com runs Apache 2.2, would it cause you a lot of trouble for that to be referenced? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: OT: performance FUD
Paul A Houle wrote: Justin Erenkrantz wrote: If it's on equivalent hardware (i.e. Linux/Intel vs. Solaris/Intel on the same box), I doubt there will be an extreme performance gap. In fact, I've often seen Solaris outperform Linux on certain types of loads. In my experience, a lot of Linux network card drivers are sub-standard; if it's supported by Solaris, there's a fair chance the driver takes full advantage of the hardware. (Netgear GigE drivers on Linux are abysmal.) -- justin I think the issue with Apache/Solaris is that process switches take a long time on Solaris. So if one uses worker and few processes (i.e. lots of threads per), then Solaris should be fine? -- Jess Holle
Re: OT: performance FUD
On Tuesday 29 November 2005 21:28, Colm MacCarthaigh wrote: On Tue, Nov 29, 2005 at 03:18:57PM -0500, Brian Akins wrote: I know that a press release is out of the question for my company. We do not endorse or disparage any product. That's understandable, for a news organisation. For our part, HEAnet has no problem being quoted, but maybe something like; Hmmm, how about an early adopters page? We could *imply* the organisations by featuring mugshots and brief profiles of both Brian and Colm as having successfully beta-tested 2.1.x in very-high-volume production environments. Just a thought :-) -- Nick Kew
Re: httpd-2.1.7 Connection-pooling Problem w/ ReverseProxy, Loadbalancer
On 11/29/2005 04:12 PM, Jim Jagielski wrote: Can you try HEAD on httpd-trunk for a fix until something more robust as far as the connections are implemented... Just for convenience: http://svn.apache.org/viewcvs?rev=349723view=rev Has someone found out out why we close the connection if r-proxyreq == PROXYREQ_PROXY || r-proxyreq == PROXYREQ_REVERSE? I fear that this is something that has survived from 2.0.x. I am also wondering why mod_proxy_http is storing the connection in the module config. Is this something from 2.0.x days where we had no connection pool or is it a security problem to share one keepalive http backend connections across different client connections and vice versa? Regards Rüdiger
Request for comments on ap_read_request refactoring Re: svn commit: r349348 - in /httpd/httpd/branches/async-read-dev: include/httpd.h server/protocol.c
[EMAIL PROTECTED] wrote: Author: brianp Date: Sun Nov 27 18:56:47 2005 New Revision: 349348 URL: http://svn.apache.org/viewcvs?rev=349348view=rev Log: More refactoring of ap_read_request() in preparation for nonblocking read support. WARNING: The code for handlng requests that exceed the field-length or number-of-fields limits isn't complete in this commit. Modified: httpd/httpd/branches/async-read-dev/include/httpd.h httpd/httpd/branches/async-read-dev/server/protocol.c I probably won't have time to do my next iteration of work on this until the weekend. In the meantime, if anybody has an opportunity to review the code, I'd appreciate any and all feedback on it. (Note that the new code is only available on the async-read-dev branch.) My remaining plans for the async reads are: - Clean up the error-case handling - Add an ap_read_async_request() that invokes the new request-reading code in a nonblocking manner - Modify ap_process_async_request() to use ap_read_async_request(), meaning that async MPMs will need to support read completion - Add read completion support to the event MPM - Port the changes back into the 2.3 trunk Brian
Re: problems with ssl in balance/proxy mode
On 11/29/2005 01:27 PM, Matthias Behrens wrote: hi everyone i am new to this list. since there is no faq available i simple post my request and see what happens. sorry if i miss any rule. i have a apache 2.0 in loadbalncing mode using mod_rewrite and mod_proxy. there have allways been problems with https/ssl requests that where longer than 8192 bytes. [..cut..] I don't get the exact problem right now. Are you using httpd 2.0.55? If yes, please have a look at PR37145 (http://issues.apache.org/bugzilla/show_bug.cgi?id=37145) and the attached patch to fix it. Maybe this hurts you. Regards Rüdiger [..cut..]
Re: PHP testing - problem with php libraries loading
Hi. Geoff: hmm, that's a good point. t/conf/extra.conf.in only affects php tests that run inside the server, such as t/response/TestAPI/foo.php. Nope. My test is in the t/response/TestPHP/ Chris: You might try getting rid of the conditional statement, just to see if that's the problem. Nope. Removing of the condition doesn't solve the problem :( By the way, how are you testing to see whether this works? Is it the output of phpinfo()? Mm.. actually I just looked into the error_log... But after I read your question I made an experiment whith my system httpd.conf and php.ini and checked phpinfo() output. I've set the extension_dir in php.ini to the wrong directory and assigned correct value in the httpd.conf. It's strange but though phpinfo() acknowledges my httpd.conf extension_dir as a 'Local Value', extensions are not loaded. It looks like settig the extension_dir in a httpd.conf (or in an extra.conf.in) just don't work with my PHP 4.3.4 :( I would appreciate your consideration... -- Filin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: svn commit: r349819 - /httpd/httpd/branches/2.2.x/STATUS
On 11/29/2005 11:23 PM, [EMAIL PROTECTED] wrote: Author: jerenkrantz Date: Tue Nov 29 14:23:30 2005 New Revision: 349819 URL: http://svn.apache.org/viewcvs?rev=349819view=rev Log: Now that the branch (but not a release just yet!) has gone GA, copy the blurb from 2.0's STATUS about the ground rules for 2.2. Does this mean we switch from CTR to RTC on the 2.2.x branch just now? Regards Rüdiger
Re: svn commit: r349713 - /httpd/httpd/trunk/Makefile.win
I'm not near my windows box, and the universal inability of any search engine to allow me to search for the literal string $MAKE is geting to me. Does anyone know exactly which is correct; $MAKE or ($MAKE) I can reverse engineer the answer tomorrow, but it's still annoying me now. It looks to me, and some others, like the latter would evaluate to (NMAKE) and yet when I made the change it got rid of the syntax error, and it looked like a compile with /nologo. Is nmake syntax really that broken? On Tue, Nov 29, 2005 at 12:37:06PM -, [EMAIL PROTECTED] wrote: Modified: httpd/httpd/trunk/Makefile.win URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/Makefile.win?rev=349713r1=349712r2=349713view=diff == --- httpd/httpd/trunk/Makefile.win (original) +++ httpd/httpd/trunk/Makefile.win Tue Nov 29 04:37:03 2005 @@ -127,7 +127,7 @@ !IFNDEF MAKEOPT # Only default the behavior if MAKEOPT= is omitted -!IF $(MAKE) == NMAKE +!IF ($MAKE) == NMAKE # Microsoft NMake options MAKEOPT=-nologo !ELSEIF ($MAKE) == make -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r349819 - /httpd/httpd/branches/2.2.x/STATUS
--On November 29, 2005 11:32:53 PM +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Does this mean we switch from CTR to RTC on the 2.2.x branch just now? Yup. (The exceptions for 2.0.x also apply to 2.2.x too.) -- justin
Re: svn commit: r349819 - /httpd/httpd/branches/2.2.x/STATUS
On 11/29/2005 11:38 PM, Justin Erenkrantz wrote: --On November 29, 2005 11:32:53 PM +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Does this mean we switch from CTR to RTC on the 2.2.x branch just now? Yup. (The exceptions for 2.0.x also apply to 2.2.x too.) -- justin Sorry for the stupid question. What exceptions? Regards Rüdiger
Re: svn commit: r349819 - /httpd/httpd/branches/2.2.x/STATUS
--On November 29, 2005 11:56:03 PM +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Sorry for the stupid question. What exceptions? Documentation and single-maintainer platforms can be changed with CTR. Everything else needs 3 +1s prior to merging. -- justin
Re: svn commit: r349819 - /httpd/httpd/branches/2.2.x/STATUS
On 11/30/2005 12:00 AM, Justin Erenkrantz wrote: --On November 29, 2005 11:56:03 PM +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: Sorry for the stupid question. What exceptions? Documentation and single-maintainer platforms can be changed with CTR. ^^^ Is this called Brad's law ;-)) Everything else needs 3 +1s prior to merging. -- justin Thanks for making the exceptions clear to me. Regards Rüdiger
Re: svn commit: r349713 - /httpd/httpd/trunk/Makefile.win
On Tue, Nov 29, 2005 at 10:36:31PM +, Colm MacCarthaigh wrote: I can reverse engineer the answer tomorrow, but it's still annoying me now. It looks to me, and some others, like the latter would evaluate to (NMAKE) and yet when I made the change it got rid of the syntax error, and it looked like a compile with /nologo. Is nmake syntax really that broken? Terminal services and an ssh-tunnel later, figured it out, $MAKE no longer evaluates to NMAKE but more something like C:\program files\Microsoft Visual Studio 8\VC\BIN\nmake.exe which is what's really causing the problem. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
+1 on Mac OS. -wsv On Nov 28, 2005, at 11:55 PM, Paul Querna wrote: These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. I am sorry for the confusion on whole move of 2.1.10 to 2.2.0. This entire situation is completely undefined in our VERSIONING file, and hasn't ever happened before with these versioning rules. I believe the best way to move forward for everyone is to vote on these 2.2.0 tarballs. Hopefully we can all learn from this, and come up with a better VERSIONING policy by the time we do 2.4. Thanks, Paul.
