Re: [PATCH] Eliminate 13 in modules/aaa/mod_authn_dbd.c / modules/aaa/mod_authnz_ldap.c
Graham Leggett wrote: Martin Kraemer wrote: Here's a patch to eliminate the 13, and to improve portability to EBCDIC machines by using apr_toupper(). Some of this fooness here revolves around charset issues, something I am not clear on for many platforms. The first question is, what is the charset of the names of environment variables on various platforms, the next is the charset of the names of LDAP attributes and database columns. It doesn't matter; we should only perform c-locale case folding. As soon as you get beyond that, the same unicode characters fold differently in different languages. Bill
Re: svn commit: r571879 - /httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c
Nick Kew wrote:
ObPedant:
14:42:30 2007 @@ -113,8 +113,8 @@
/* we break the URL into host, port, uri */
if (APR_SUCCESS != apr_uri_parse_hostinfo(p, url, uri)) {
-return ap_proxyerror(r, HTTP_BAD_REQUEST,
- apr_pstrcat(p, URI cannot be parsed: , url,
NULL));
+return ap_proxyerror(r, HTTP_BAD_REQUEST, apr_pstrcat(p,
+ URI cannot be parsed: , url, NULL));
The second arg to ap_pstrcat is presented as a new arg to ap_proxyerror.
The old formatting was better.
+1 to niq's observation
- this is now quite illegible in terms of how it is doing what it does.
Re: svn commit: r571927 - /httpd/httpd/trunk/docs/manual/mod/mod_include.xml
[EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=571927view=rev Log: * There is no context location. But this directive should in .htaccess files. I used OR_LIMIT, which I understand to be in directory and location sections only. The thinking was that the administrator might not want people uploading content that was able to test URL access on the server, though it's up to debate as to whether this is just being overly paranoid? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r571928 - /httpd/httpd/branches/2.2.x/STATUS
[EMAIL PROTECTED] wrote: + rpluem says: Without r571927 the documentation for mod_authn_dbd fails + to build. I found that while trying to write the documentation, Firefox refused to parse the XML file at the start, complaining about the nbsp; non breaking space sequence. Is nbsp; valid in XML? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r571928 - /httpd/httpd/branches/2.2.x/STATUS
* Graham Leggett wrote: [EMAIL PROTECTED] wrote: + rpluem says: Without r571927 the documentation for mod_authn_dbd fails + to build. I found that while trying to write the documentation, Firefox refused to parse the XML file at the start, complaining about the nbsp; non breaking space sequence. Is nbsp; valid in XML? Given the proper Doctype, sure. However, firefox refuses a lot. This does not mean it's not valid. The char entity problem is well-known, but invalid (firefox only uses DTDs out of the chrome scheme, for whatever reason). The doc build system incorporates all HTML char entities and is the authoritative source whether a document can be transformed or not. nd -- Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine beiden Gefährten nicht zu zählen brauchte -- Karl May, Winnetou III Im Westen was neues: http://pub.perlig.de/books.html#apache2
Re: svn commit: r571927 - /httpd/httpd/trunk/docs/manual/mod/mod_include.xml
On 09/02/2007 02:22 PM, Graham Leggett wrote: [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=571927view=rev Log: * There is no context location. But this directive should in .htaccess files. I used OR_LIMIT, which I understand to be in directory and location sections only. From include/http_config.h: #define OR_LIMIT 1»· /** *.conf inside Directory or Location »···»···»···»···and .htaccess when AllowOverride Limit */ The thinking was that the administrator might not want people uploading content that was able to test URL access on the server, though it's up to debate as to whether this is just being overly paranoid? Deny from / Allow from / Order is also OR_LIMIT, but AFAIK it can be used in .htaccess if AllowOverride Limit is set. I think you might have been looking for ACCESS_CONF in this case (see ModMimeUsePathInfo). Regards Rüdiger
Re: svn commit: r571928 - /httpd/httpd/branches/2.2.x/STATUS
André Malo wrote: Is nbsp; valid in XML? Given the proper Doctype, sure. However, firefox refuses a lot. This does not mean it's not valid. The char entity problem is well-known, but invalid (firefox only uses DTDs out of the chrome scheme, for whatever reason). The doc build system incorporates all HTML char entities and is the authoritative source whether a document can be transformed or not. The docs at http://httpd.apache.org/docs-project/docsformat.html imply that modern browsers should work and that an older browser might not, and when Firefox didn't my first thought was that the XML was at fault, and not Firefox. Is it possible to update this page to clarify that one should always rely on the reference transformation using Xalan+Xerces because concluding anything is broken? At the moment, emphasis is placed on Xalan+Xerces being used to prevent massive diffs only. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r571927 - /httpd/httpd/trunk/docs/manual/mod/mod_include.xml
Ruediger Pluem wrote: From include/http_config.h: #define OR_LIMIT 1»· /** *.conf inside Directory or Location »···»···»···»···and .htaccess when AllowOverride Limit */ Ok this makes sense - the directive is still under the administrator's control, so this works. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Revisiting UDP support (for trunk)
Hi all, I've been quietly hacking away at getting UDP support working with trunk (prefork/unix only, for starters). While I had a decent amount of success, I eventually got stuck: my original naive plan had been to poll, recvfrom (to get peer address), dup the socket, connect the dup-ed socket and close the dup-ed socket after processing a single request (as defined by the connection/protocol handlers). The hope was that since we never connected the original socket, it would still do something useful. To make a long story short, I found that it wasn't doing anything of the sort. Before I launch into a new tactic, I wanted to see if someone has a better idea than me - the only thing that pops into my mind is moving some sort of pointers to the UDP listeners into the scoreboard (or some other R/W shared area) and simply letting the children/workers lock used sockets (so other children/workers don't poll it), and completely replace them after they're used. There are a lot of disadvantages to doing that, I think, but I can't dream up a smarter solution. Anyone have any ideas? Issac
Re: Revisiting UDP support (for trunk)
As I hit send on that last email, it occurred to me that another, possibly more elegant, solution would be to patch the core_input and core_output filters to use recvfrom and sendto if a non-stream socket is detected. In that case, I think the what needs to be done is to modify the core create_connection to detect a non-stream socket and not set up remote information. Then core_input would need to update the peer information in the conn_rec, and use recvfrom, while core_output would use sendto (with the saved peer information). It's probably tricky, but appeals to me more than letting children muck with the listeners... Issac Issac Goldstand wrote: Hi all, I've been quietly hacking away at getting UDP support working with trunk (prefork/unix only, for starters). While I had a decent amount of success, I eventually got stuck: my original naive plan had been to poll, recvfrom (to get peer address), dup the socket, connect the dup-ed socket and close the dup-ed socket after processing a single request (as defined by the connection/protocol handlers). The hope was that since we never connected the original socket, it would still do something useful. To make a long story short, I found that it wasn't doing anything of the sort. Before I launch into a new tactic, I wanted to see if someone has a better idea than me - the only thing that pops into my mind is moving some sort of pointers to the UDP listeners into the scoreboard (or some other R/W shared area) and simply letting the children/workers lock used sockets (so other children/workers don't poll it), and completely replace them after they're used. There are a lot of disadvantages to doing that, I think, but I can't dream up a smarter solution. Anyone have any ideas? Issac
Re: svn commit: r571928 - /httpd/httpd/branches/2.2.x/STATUS
* Graham Leggett wrote: André Malo wrote: Is nbsp; valid in XML? Given the proper Doctype, sure. However, firefox refuses a lot. This does not mean it's not valid. The char entity problem is well-known, but invalid (firefox only uses DTDs out of the chrome scheme, for whatever reason). The doc build system incorporates all HTML char entities and is the authoritative source whether a document can be transformed or not. The docs at http://httpd.apache.org/docs-project/docsformat.html imply that modern browsers should work and that an older browser might not, and when Firefox didn't my first thought was that the XML was at fault, and not Firefox. Is it possible to update this page to clarify that one should always rely on the reference transformation using Xalan+Xerces because concluding anything is broken? At the moment, emphasis is placed on Xalan+Xerces being used to prevent massive diffs only. Rephrased the browser note a bit. Is it better now? nd -- Muschelflucht-Zusatzeinrichtung. Shell-Escape ist ja noch klar, aber `Zusatzeinrichtung'? extension? Feature. -- gefunden in de.org.ccc
Re: svn commit: r571928 - /httpd/httpd/branches/2.2.x/STATUS
On Sep 2, 2007, at 5:24 AM, Graham Leggett wrote: [EMAIL PROTECTED] wrote: Is nbsp; valid in XML? The answer is complicated. One approach is to use #xA0; which is kinda ugly but works in lots more places. -T
Re: svn commit: r571928 - /httpd/httpd/branches/2.2.x/STATUS
On 02.09.2007, at 17:06, Tim Bray wrote: On Sep 2, 2007, at 5:24 AM, Graham Leggett wrote: [EMAIL PROTECTED] wrote: Is nbsp; valid in XML? The answer is complicated. One approach is to use #xA0; which is kinda ugly but works in lots more places. -T Yep, quite complicated - it has to do with Mozilla not loading external entities, etc. It's a long-known bug (since ~2000, see bugs #22942, #69799, #255747 and several others in Mozilla's Bugzilla); there are several work-arounds like using only internal entity defs, using #xA0 and co or even populating Mozilla's bin/res/dtd directory but not one of them is really practical so we decided to just live with it... :( Cheers, Erik
Re: svn commit: r571872 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_include.xml modules/filters/mod_include.c modules/filters/mod_include.h
André Malo wrote: Is there a particular reason, that you changed the public context instead of the internal (private) one? Because I was under the incorrect impression that all the other directives were being written there. I've changed it - thanks for catching it out. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r571872 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_include.xml modules/filters/mod_include.c modules/filters/mod_include.h
* Graham Leggett wrote: André Malo wrote: Is there a particular reason, that you changed the public context instead of the internal (private) one? Because I was under the incorrect impression that all the other directives were being written there. I've changed it - thanks for catching it out. Ah, was just wondering. Thanks. nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2
