mod_ssl useless CRL object reinitialisation ?
Hello, In ssl_engine_kernel.c, line 1439 in ssl_callback_SSLVerify_CRL(), we reinitialise a new CRL by calling object SSL_X509_STORE_lookup(). This was already performed at the beginning of the function. Couldn't we reuse the first one instead of cleaning it and reusing it ? I don't see any modification of the structure. Regards Nick
ProxyErrorOverride inside a location - compatibility problem with SOAP
Hello, Is there any reason to not accept this directive inside a location ? There is a major reason to use a different setting inside a location: - for security reason, you set it to "on" - if you have a Web service, you are obliged to set it to "off" because SOAP fault error messages are reported with a status 500 Couldn't we just move the "error_override_set" & "error_override" to the "proxy_dir_conf" struct ? Thanks, Nick
Re: ProxyErrorOverride inside location
The development was actually done in 2.2. I do not see any difference between 2.2 & 2.3 regarding this. Eric Covener wrote: On Tue, Feb 3, 2009 at 5:39 AM, Nick Gearls wrote: A patch is submitted: https://issues.apache.org/bugzilla/show_bug.cgi?id=46656 Here are the modifs: - added |ACCESS_CONF to AP_INIT_FLAG - error_override & error_override_set are moved to proxy_dir_conf - set_proxy_error_override() is modified to use provided dconf* As I explained, this is very useful when using Web Services, as SOAP errors are reported inside status 500 pages. Will this be added ? While it's not my strong suit, it seems like the change to mod_proxy.h (per-server conf and pe-dir conf) presents some hurdles in backporting this to 2.2.x
Re: ProxyErrorOverride inside location
I understand now. What about 2.3 ? To be honest, I really cannot imagine another module using that value, even in 2.2. But we have to be strict, I agree. Does the code satisfies everybody, or should I rework it in any way ? Eric Covener wrote: On Tue, Feb 3, 2009 at 9:33 AM, Nick Gearls wrote: The development was actually done in 2.2. I do not see any difference between 2.2 & 2.3 regarding this. Since the per-server config appears in a public header, it's fair game that other modules have a reference to it. They wouldn't expect that to change in 2.2 maintenance.
ProxyErrorOverride inside location
A patch is submitted: https://issues.apache.org/bugzilla/show_bug.cgi?id=46656 Here are the modifs: - added |ACCESS_CONF to AP_INIT_FLAG - error_override & error_override_set are moved to proxy_dir_conf - set_proxy_error_override() is modified to use provided dconf* As I explained, this is very useful when using Web Services, as SOAP errors are reported inside status 500 pages. Will this be added ?
Re: ProxyErrorOverride inside location
It seems there is a little problem in my code. When defining "ProxyErrorOverride On" at the vhost level, then "ProxyErrorOverride Off" at a directory level, the directive does not seem to work at the directory level. The merge works correctly, I traced it, and "error_override" is set to 1 at global level, then to 0 at the dir level. But in "ap_proxy_http_process_response()", dconf->error_override" is always set to 1. dconf is built as usual: proxy_dir_conf *dconf = ap_get_module_config(r->per_dir_config, &proxy_module); Any idea ? Thanks, Nick Nick Gearls wrote: A patch is submitted: https://issues.apache.org/bugzilla/show_bug.cgi?id=46656 Here are the modifs: - added |ACCESS_CONF to AP_INIT_FLAG - error_override & error_override_set are moved to proxy_dir_conf - set_proxy_error_override() is modified to use provided dconf* As I explained, this is very useful when using Web Services, as SOAP errors are reported inside status 500 pages. Will this be added ?
mod_substitute & back-references
Hi, Is there any plan to support back-references in mod_substitute ? mod_sed could obviously do it, but it must be much heavier. Thanks, Nick
Re: mod_substitute & back-references
When using Substitute s|toreplace|*$1*|ni I get "*$1" in my page. There is no info about backtracking on the doc page, so maybe I don't use the right syntax ? Regards, Nick Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Nick Gearls Gesendet: Montag, 9. März 2009 14:35 An: Development Apache Betreff: mod_substitute & back-references Hi, Is there any plan to support back-references in mod_substitute ? mod_substitute already supports backreferences (and always has). Regards Rüdiger
Re: mod_substitute & back-references
Oops, stupid ! Anyway, a real problem: Substitute s|(toreplace)|*replaced[$1]*|qi translates "toreplace" into "*replaced[*replaced[*replaced[toreplace]*]*]*" Don't we expect the q flag to stop any replacement after the first one? Thanks, Nick Eric Covener wrote: On Tue, Mar 10, 2009 at 8:01 AM, Nick Gearls wrote: When using Substitute s|toreplace|*$1*|ni I get "*$1" in my page. You have to capture something.
Re: mod_substitute & back-references
Same thing Plüm, Rüdiger, VF-Group wrote: Have you tried without the q flag? Regards Rüdiger -Ursprüngliche Nachricht- Von: Nick Gearls Gesendet: Mittwoch, 11. März 2009 10:04 An: dev@httpd.apache.org Betreff: Re: mod_substitute & back-references Oops, stupid ! Anyway, a real problem: Substitute s|(toreplace)|*replaced[$1]*|qi translates "toreplace" into "*replaced[*replaced[*replaced[toreplace]*]*]*" Don't we expect the q flag to stop any replacement after the first one? Thanks, Nick Eric Covener wrote: On Tue, Mar 10, 2009 at 8:01 AM, Nick Gearls wrote: When using Substitute s|toreplace|*$1*|ni I get "*$1" in my page. You have to capture something.
Re: mod_substitute & back-references
It's not replaceAll vs. replaceFirst, it's replace recursively or not. For me, it should not be recursive (independently of the q flag, I agree with you Jim). Actually, if it is recursive, it should be a never-ending replacement in this case, which would be a (not voluntary) denial of service. I do not expect this. Nick Jim Jagielski wrote: On Mar 11, 2009, at 5:03 AM, Nick Gearls wrote: Oops, stupid ! Anyway, a real problem: Substitute s|(toreplace)|*replaced[$1]*|qi translates "toreplace" into "*replaced[*replaced[*replaced[toreplace]*]*]*" Don't we expect the q flag to stop any replacement after the first one? Not necessarily, no... it's not a replaceAll vs. replaceFirst flag.
Re: mod_substitute & back-references
You can reproduce the problems on this file: abc 1. Substitute s|abc|abc|n -> OK: "abc" 2. Substitute s|abc|+abc| -> NOK: "+++abc" 3. Substitute s|abc|++abc|nq -> NOK: "++abc" 4. Substitute s|abc|+++abc|q -> NOK: "+abc" q & n flags have no influence. I also managed to have a full recursive loop (Apache eating memory up to a crash), but I cannot reproduce it anymore !?! Regards, Nick Ruediger Pluem wrote: On 03/12/2009 06:13 PM, Nick Gearls wrote: Anyway, a real problem: Substitute s|(toreplace)|*replaced[$1]*|qi translates "toreplace" into "*replaced[*replaced[*replaced[toreplace]*]*]*" Hm. I cannot reproduce this. Mind to attach the file to which you applied this? Regards Rüdiger
Re: mod_substitute & back-references
No, only once at a time. It's just to give several examples Regards, Nick Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Nick Gearls Gesendet: Freitag, 13. März 2009 13:48 An: dev@httpd.apache.org Betreff: Re: mod_substitute & back-references You can reproduce the problems on this file: abc 1. Substitute s|abc|abc|n -> OK: "abc" 2. Substitute s|abc|+abc| -> NOK: "+++abc" 3. Substitute s|abc|++abc|nq -> NOK: "++abc" 4. Substitute s|abc|+++abc|q -> NOK: "+abc" Are you using all these above at the same time? Regards Rüdiger
Re: mod_substitute & back-references
Different result, but still incorrect: Substitute s|abc|---abc+++|n changes "abc" to "-abc+" Regards, Nick Plüm, Rüdiger, VF-Group wrote: Ok. Now I could reproduce it. Could you please check if the following patch fixes it for you? Index: modules/filters/mod_substitute.c === --- modules/filters/mod_substitute.c(revision 753197) +++ modules/filters/mod_substitute.c(working copy) @@ -199,7 +199,6 @@ tmp_b = apr_bucket_transient_create(s1, strlen(s1), f->r->connection->bucket_alloc); APR_BUCKET_INSERT_BEFORE(b, tmp_b); -tmp_b = APR_BUCKET_NEXT(b); apr_bucket_delete(b); b = tmp_b; } @@ -249,7 +248,6 @@ tmp_b = apr_bucket_transient_create(s1, strlen(s1), f->r->connection->bucket_alloc); APR_BUCKET_INSERT_BEFORE(b, tmp_b); -tmp_b = APR_BUCKET_NEXT(b); apr_bucket_delete(b); b = tmp_b; } Regards Rüdiger -Ursprüngliche Nachricht- Von: Nick Gearls Gesendet: Freitag, 13. März 2009 15:26 An: dev@httpd.apache.org Betreff: Re: mod_substitute & back-references No, only once at a time. It's just to give several examples Regards, Nick Plüm, Rüdiger, VF-Group wrote: -----Ursprüngliche Nachricht- Von: Nick Gearls Gesendet: Freitag, 13. März 2009 13:48 An: dev@httpd.apache.org Betreff: Re: mod_substitute & back-references You can reproduce the problems on this file: abc 1. Substitute s|abc|abc|n -> OK: "abc" 2. Substitute s|abc|+abc| -> NOK: "+++abc" 3. Substitute s|abc|++abc|nq -> NOK: "++abc" 4. Substitute s|abc|+++abc|q -> NOK: "+abc" Are you using all these above at the same time? Regards Rüdiger
Re: mod_substitute & back-references
Same file, mod_substitute from 2.2.11, test under Windows Regards, Nick Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Nick Gearls Gesendet: Montag, 16. März 2009 10:02 An: dev@httpd.apache.org Betreff: Re: mod_substitute & back-references Different result, but still incorrect: Substitute s|abc|---abc+++|n changes "abc" to "-abc+" I cannot reproduce this. Mind to share your configuration? I used the following file as a source for the filter: abc Regards Rüdiger
Re: mod_substitute & back-references
I found more info: I had mod_proxy_html loaded. If I remove it, it changes "abc" to "--abc++", thus twice instead of 3 times. Strange, isn't it ? I performed the test on a minimal config, and it works correctly. I cannot reproduce the mod_proxy_html problem on this minimal config either. I suppose there is another interaction. I'll try to make more tests. Regards, Nick Nick Gearls wrote: Same file, mod_substitute from 2.2.11, test under Windows Regards, Nick Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Nick Gearls Gesendet: Montag, 16. März 2009 10:02 An: dev@httpd.apache.org Betreff: Re: mod_substitute & back-references Different result, but still incorrect: Substitute s|abc|---abc+++|n changes "abc" to "-abc+" I cannot reproduce this. Mind to share your configuration? I used the following file as a source for the filter: abc Regards Rüdiger
mod_substitute & \n
I found a problem with handling of new lines in mod_substitute. Take the following file as example 1. If I use "Substitute s/\n/1/", it works almost correctly: 1 1 1 1 Note that it does not replace the new line, but adds the replacement after it. This is quite weird. 2. If I use "Substitute s/\n/2/" or "Substitute s/\n/2/", the file is unchanged Could somebody explain how newlines are handled ? Can we use them inside a pattern ? Thanks, Nick
Substitute bug
In a page containing only "abcdef" (inside the ), and the following directives, Substitute s~(abc.*)$~$1~q Substitute s~def~XXX~ the second directive should be ignored, because of the q flag on the first one. The result should be "abcdef". However, the result is "abcXXX". Did I miss something ? PS: I applied Rüdiger Plüm's patch: > Index: modules/filters/mod_substitute.c > === > --- modules/filters/mod_substitute.c(revision 753197) > +++ modules/filters/mod_substitute.c(working copy) > @@ -199,7 +199,6 @@ > tmp_b = apr_bucket_transient_create(s1, strlen(s1), > f->r->connection->bucket_alloc); > APR_BUCKET_INSERT_BEFORE(b, tmp_b); > -tmp_b = APR_BUCKET_NEXT(b); > apr_bucket_delete(b); > b = tmp_b; > } > @@ -249,7 +248,6 @@ > tmp_b = apr_bucket_transient_create(s1, strlen(s1), > f->r->connection->bucket_alloc); > APR_BUCKET_INSERT_BEFORE(b, tmp_b); > -tmp_b = APR_BUCKET_NEXT(b); > apr_bucket_delete(b); > b = tmp_b; > } Regards, Nick
mod_substitute memory problem
Hello, There seems to be a memory problem when substituing something on very long lines (several hundreds KB). this problem is different from bug 44948 (I applied this patch). When using something like "Substitute s/string1/string2/" on a 300 KB line with 30 times "string1" on the line, there are 2 problems: 1. It uses a huge amount of memory, as - I think - it reallocates a new buffer (300 KB) before each substitute without freeing the previous one 2. The memory is not freeed at the end of the HTTP request. Maybe is it due to Keep-alive? If using the "q" switch to not flatten the buckets, it uses almost no memory. Btw, it correctly handles more 60 substitutions on the same line (some shorter, some longer) without the q flag !?! When exactly is this flag needed? In macro SEDSCAT, we have s2 = apr_pstrmemdup(pool, buff, blen); s1 = apr_pstrcat(pool, s1, s2, NULL); Shouldn't we free the previous s1 buffer? Anyway, I do not understand why the memory is not released, as the pool is supposed to be destroyed. Regards, Nick
Re: mod_substitute memory problem
The problem is real. I have an application which generates one line of about 300 KB :-( In this case, Apache eats up all the memory (about 1 GB), and never gives it back to the OS - game over - reboot ! How could this be solved? Thanks, Nick Dan Poirier wrote: Nick Gearls writes: There seems to be a memory problem when substituing something on very long lines (several hundreds KB). this problem is different from bug 44948 (I applied this patch). When using something like "Substitute s/string1/string2/" on a 300 KB line with 30 times "string1" on the line, there are 2 problems: 1. It uses a huge amount of memory, as - I think - it reallocates a new buffer (300 KB) before each substitute without freeing the previous one I think you're right - most of the working memory is not released until the request is over. This is kind of a worst-case for mod_substitute's temporary memory usage. Is this a problem in real cases? Or just in artificial testing? If these are real requests, maybe if you tell a little more about them, we can find a better solution. 2. The memory is not freeed at the end of the HTTP request. Maybe is it due to Keep-alive? If by "the memory is not freed", you mean the memory usage for the http process as reported by the OS doesn't go down, that's right. But at the end of the request, the memory should be released back to Apache to re-use. You can test this by repeating your test several times - after the first time, the process's memory usage should not keep going up the way it does the first time. If that's a problem in your case, you can set MaxMemFree to ask Apache to release memory by calling free() above a certain threshold. Even then, whether the process releases the memory back to the OS depends on the OS, so it might not gain you anything. But if this is going to happen very often, you might as well let Apache hold on to the memory; it's just going to grab it back again the next time this happens. If using the "q" switch to not flatten the buckets, it uses almost no memory. Btw, it correctly handles more 60 substitutions on the same line (some shorter, some longer) without the q flag !?! When exactly is this flag needed? Don't know about this one. In macro SEDSCAT, we have s2 = apr_pstrmemdup(pool, buff, blen); s1 = apr_pstrcat(pool, s1, s2, NULL); Shouldn't we free the previous s1 buffer? Pools don't provide a way of freeing individual allocations; you have to destroy the whole pool. Anyway, I do not understand why the memory is not released, as the pool is supposed to be destroyed. See above.
Re: mod_substitute memory problem
Hi Nick, Do you mean that mod_sed should be used instead of mod_substitute? Because it is more complete, or more mature? I only need the substitution. About the flattening: is the q flag only needed if you want to use two subst on the same line with overlapping between them? Thanks, Nick Nick Kew wrote: On Wed, 10 Jun 2009 13:11:16 +0200 Nick Gearls wrote: 2. The memory is not freeed at the end of the HTTP request. Maybe is it due to Keep-alive? It's recycled within the server. If using the "q" switch to not flatten the buckets, it uses almost no memory. Btw, it correctly handles more 60 substitutions on the same line (some shorter, some longer) without the q flag !?! When exactly is this flag needed? Rarely, IMO. When I wrote mod_line_edit - which does essentially the same as mod_substitute - I didn't provide that option, and instead documented it as not working with overlapping substitutions. Another "slow by default" flag in mod_substitute is that it uses regexps by default. Turn them off unless you definitely need them! Anyway, I do not understand why the memory is not released, as the pool is supposed to be destroyed. It's recycled within the server. mod_sed is now the state-of-the-art. Perhaps a visit to http://httpd.apache.org/docs/2.3/mod/mod_sed.html would be in order.
Re: mod_substitute memory problem
Yes, that's what I meant. The kind of thing that (surprisingly) works is s/(pattern)/---toremove---$1/q s/---toremove---//q The second one should obviously use the n flag, but even with a regex it works. I also tried with the second string longer or shorter, and it always works (at least on my test page). Can I really consider this as safe? Thanks, Nick Ruediger Pluem wrote: On 06/10/2009 06:18 PM, Nick Gearls wrote: Hi Nick, Do you mean that mod_sed should be used instead of mod_substitute? Because it is more complete, or more mature? I only need the substitution. About the flattening: is the q flag only needed if you want to use two subst on the same line with overlapping between them? It's the other way round: If you have two subst with overlappings using the q flag might result in missing substitutions. As this does not seem to be the case for your problem it is safe (and good) to use it as it solves your memory problem. Regards Rüdiger
Certificate chain order not conform to TLS standard
Hello, I get problems with a picky SSL client complaining that Apache does not send the certificate chain in the right order (server/CA/root). Is that possible? Doesn't Apache (I am using 2.2.4) honor the RFC? Thanks, Nick
Re: Certificate chain order not conform to TLS standard
I tried both order: SSLCertificateFile conf/ssl/server.pem SSLCertificateChainFile conf/ssl/chain.pem where server.pem contains both the cert and the private key, and chain.pem contains either CA/root or root/CA Plüm, Rüdiger, VF-Group wrote: -Original Message- From: Nick Gearls [mailto:nickgea...@gmail.com] Sent: Mittwoch, 12. August 2009 16:32 To: Development Apache Subject: Certificate chain order not conform to TLS standard Hello, I get problems with a picky SSL client complaining that Apache does not send the certificate chain in the right order (server/CA/root). Is that possible? Doesn't Apache (I am using 2.2.4) honor the RFC? This is not a matter of httpd but a matter in which order you put the certificates of the chain in the chainfile. Try changing their order in the chainfile. Regards Rüdiger
mod_substitute strange behaviour
I'm not sure this is really desired: 1. More or less normal/abnormal case: s/123/abc123def/ -> "*123*" becomes "abcabc123defdef" Substitution is made twice (why not 3 times, 4 times,... ?). Flatening the bucket or not does not changing anything. I suppose we could argue that the author has to ensure that there is no cycle, although I find this a major problem. Can't we add a flag to replace only once? That would be neat. 2. This one is really difficult to understand: s/123/abcxxxdef/ s/xxx/123/ -> "*123*" becomes "abcabc123defdef", again By issuing to successive commands, I cannot understand why the first one is executed again after the second one ?!? Is this an expected behaviour? Thanks, Nick
Re: mod_substitute strange behaviour
Last version from trunk Jim Jagielski wrote: On Nov 19, 2009, at 12:12 PM, Nick Gearls wrote: I'm not sure this is really desired: 1. More or less normal/abnormal case: s/123/abc123def/ -> "*123*" becomes "abcabc123defdef" Substitution is made twice (why not 3 times, 4 times,... ?). Flatening the bucket or not does not changing anything. I suppose we could argue that the author has to ensure that there is no cycle, although I find this a major problem. Can't we add a flag to replace only once? That would be neat. 2. This one is really difficult to understand: s/123/abcxxxdef/ s/xxx/123/ -> "*123*" becomes "abcabc123defdef", again By issuing to successive commands, I cannot understand why the first one is executed again after the second one ?!? Is this an expected behaviour? What version?
mod_substitute bugs 47220, 47215 & 48291
Hello, Is somebody still working on mod_substitute, or is this module abandoned? The first bug is an enhancement, but the last 2 ones are blocking ones. Could somebody work on this? Thanks Nick
mod_proxy and chunked encoding
Hello, Although I can see a lot of problems related to chunked encoding, it is not clear to me if it is correctly supported in latests versions. During tests with 2.2.4, I found the following problem: when the back-end sends chunked encoding to an Apache reverse proxy (see below for loaded modules), it seems that Apache does not understands it is chunked encoded (although the header is present), and sends the complete packet with the chunks length as part of the (non chunked encoded) message. When suppressing the chunked encoding (by forcing HTTP 1.0 with "setenv force-proxy-request-1.0"), it works smoothly. Is this supposed to be one of the known bugs - I don't see corresponding one (no mod_filter, mod_deflate, etc.)? Details: - Answer from the back-end - HTTP/1.1 200 OK Date: Tue, 01 Jun 2010 12:01:23 GMT Server: ***back-end** Content-Type: text/html; charset=utf-8 Content-Length: 28903 Transfer-Encoding: chunked Connection: close 70d9 "http://www.w3.org/TR/html4/loose.dtd";> … 0 - Answer from the reverse proxy - HTTP/1.1 200 OK Date: Tue, 01 Jun 2010 12:01:23 GMT Server: ***front-end** Content-Type: text/html; charset=utf-8 Vary: Accept-Encoding,User-Agent Content-Length: 28903 Connection: close 70d9 "http://www.w3.org/TR/html4/loose.dtd";> … 0 - Relevant loaded modules: * mod_rewrite * mod_substitute * mod_include * mod_proxy * mod_proxy_http Regards, Nick
Re: mod_proxy and chunked encoding
I cannot try another version in the environment where I have the problem :-( But I can't find any (explicit) fix for it in newer versions... Original Message Subject: RE: mod_proxy and chunked encoding Date: Wed, 2 Jun 2010 14:34:43 +0200 From: "Plüm, Rüdiger, VF-Group" To: , -Original Message----- From: Nick Gearls Sent: Mittwoch, 2. Juni 2010 14:06 To: Development Apache Subject: mod_proxy and chunked encoding Hello, Although I can see a lot of problems related to chunked encoding, it is not clear to me if it is correctly supported in latests versions. During tests with 2.2.4, I found the following problem: when the 2.2.4 is fairly old. Have you tried with a more recent version? Regards Rüdiger
Bug 47066 - Header edit replacement string is not a format string
Hello, I'd like to extend the patch to allow also format string into the regex part, but 'parse_format_string' looks a bit hard-coded to the value part. How could I use to parse the regex? Thanks, Nick
mod_substitute erratic behaviour
mod_substitute, when triggered on the attached text with any
substitution, screws up the message: it either completely mixes
characters and truncates the text, or leads to an encoding error
(detected by the browser).
Ex: s/e/x/n
Remark: when using the "q" parameter, it works. The "n" parameter has no
impact.
I cannot reproduce that on any other text (big one, very long lines, etc.)
Any idea?
Nick
--
if(!window.Richfaces){window.Richfaces={};}
Richfaces.mergeStyles=function(userStyles,commonStyles){var i;for(i in userStyles){if(typeof
userStyles[i]=="object"){this.mergeStyles(userStyles[i],commonStyles[i]);}else{if(commonStyles[i]){commonStyles[i]+="
"+userStyles[i];}else{commonStyles[i]=userStyles[i];}}}
return commonStyles;};Richfaces.getComputedStyle=function(eltId,propertyName){var
elt=$(eltId);if(elt.nodeType!=Node.ELEMENT_NODE){return"";}
if(elt.currentStyle){return elt.currentStyle[propertyName];}
if(document.defaultView&&document.defaultView.getComputedStyle){var
styles=document.defaultView.getComputedStyle(elt,null);if(styles){return
styles.getPropertyValue(propertyName);}}
return"";};Richfaces.getComputedStyleSize=function(eltId,propertyName){var
value=Richfaces.getComputedStyle(eltId,propertyName);if(value){value=value.strip();value=value.replace(/px$/,"");return
parseFloat(value);}
return 0;};Richfaces.getWindowSize=function(){var
myWidth=0,myHeight=0;if(typeof(window.innerWidth)=='number'){myWidth=window.innerWidth;myHeight=window.innerHeight;}else
if(document.documentElement&&(document.documentElement.clientWidth||document.documentElement.clientHeight)){myWidth=document.documentElement.clientWidth;myHeight=document.documentElement.clientHeight;}else
if(document.body&&(document.body.clientWidth||document.body.clientHeight)){myWidth=document.body.clientWidth;myHeight=document.body.clientHeight;}
return{"width":myWidth,"height":myHeight};};Richfaces.removePX=function(str){var
pxIndex=str.indexOf("px")
if(pxIndex==-1)return str;return
str.substr(0,pxIndex);};Richfaces.visitTree=function(root,callback){var
node=root;if(!node){node=document;}
callback.call(this,node);var
child=node.firstChild;while(child){Richfaces.visitTree(child,callback);child=child.nextSibling;}};Richfaces.getNSAttribute=function(name,element){if(element.getAttributeNS){var
attr=element.getAttributeNS('http://richfaces.ajax4jsf.org/rich',name);if(attr){return
attr;}}
var attributes=element.attributes;var attrName="rich:"+name;var
attr=attributes[attrName];if(attr){return attr.nodeValue;}
return
null;};Richfaces.VARIABLE_NAME_PATTERN=/^\s*[_,A-Z,a-z][\w,_\.]*\s*$/;Richfaces.getObjectValue=function(str,object){var
a=str.split(".");var value=object[a[0]];var
c=1;while(value&&c=0&&oy>=0&&theBest.square=0&&oy>=0&&theBest.square=0&&oy>=0&&theBest.squares){ox=theBest.x;oy=theBest.y}}
element.style.left=ox+'px';element.style.top=oy+'px';};Richfaces.Position.getOffsetDimensions=function(element){element=$(element);var
display=$(element).getStyle('display');if(display!='none'&&display!=null)
return{width:element.offsetWidth,height:element.offsetHeight};var
els=element.style;var originalVisibility=els.visibility;var
originalPosition=els.position;var
originalDisplay=els.display;els.visibility='hidden';els.position='absolute';els.display='block';var
originalWidth=element.offsetWidth;var
originalHeight=element.offsetHeight;els.display=originalDisplay;els.position=originalPosition;els.visibility=originalVisibility;return{width:originalWidth,height:originalHeight};};Richfaces.Position.checkCollision=function(elementRect,windowRect,windowOffset)
{if(elementRect.left>=windowRect.left&&elementRect.top>=windowRect.top&&elementRect.right<=windowRect.right&&elementRect.bottom<=windowRect.bottom)
return 0;var
rect={left:(elementRect.left>windowRect.left?elementRect.left:windowRect.left),top:(elementRect.top>windowRect.top?elementRect.top:windowRect.top),right:(elementRect.right
mod_substitute tags parsing
Hello,
I took the tags parsing code from mod_headers to incorporate it to
mod_substitute.
It almost works, but I cannot obtain the handlers via apr_hash_get() -
even the locally defined ones (%D & %t).
They are all registered:
static int tags_pre_config(apr_pool_t *p, apr_pool_t *plog,
apr_pool_t *ptemp)
{
format_tag_hash = apr_hash_make(p);
register_format_tag_handler("D", (const void
*)tags_request_duration);
register_format_tag_handler("t", (const void *)tags_request_time);
register_format_tag_handler("e", (const void
*)tags_request_env_var);
register_format_tag_handler("s", (const void
*)tags_request_ssl_var);
return OK;
}
Any idea what could be the problem?
Btw, I copied the code from mod_headers and it is 98% identical, so I'll
modularise it to be 100% portable between these 2 modules (and others).
The next step will be to remove it from the modules itself and make the
static functions global.
Thanks,
Nick
Re: mod_substitute tags parsing
If somebody from mod_log_config wants to discuss with me to generalise
the code to be usable also without request_rec/server_req and pools, I
can try to do it cleanly for the first patch proposal.
Any idea why I cannot obtain the handlers via apr_hash_get()?
Or maybe what I could check to debug the problem (I do not know how this
register_format_tag_handler() works.
Nick
Original Message
Subject: Re: mod_substitute tags parsing
Date: Sat, 6 Nov 2010 21:51:26 +0100 (CET)
From: Stefan Fritsch
To: Development Apache , nickgea...@gmail.com
On Sat, 6 Nov 2010, Nick Gearls wrote:
Btw, I copied the code from mod_headers and it is 98% identical, so I'll
modularise it to be 100% portable between these 2 modules (and others). The
next step will be to remove it from the modules itself and make the static
functions global.
This looks very similar to the code in mod_log_config. Maybe it could be
made general enough that all three modules could use the same code?
OTOH, the ErrorLog formatter can probably not use the same code. It has to
work without request_rec or server_req and should not use pools for memory
allocation.
BTW, I have also thought about making it possible to evaluate an ap_expr
to a string. Then one could use a string like "%{ENV:xxx} %{IPV6}".
Would this be a useful alternative?
Re: mod_substitute tags parsing
Actually, the problem is that apr_table_get(r->subprocess_env, a) always
returns null.
I suppose that the problem lies in the request variable "r".
I am using f->r where f is the "ap_filter_t" given as parameter to
do_pattmatch().
Should I use another one,
Thanks,
Nick
Original Message
Subject: mod_substitute tags parsing
Date: Sat, 06 Nov 2010 18:19:33 +0100
From: Nick Gearls
Reply-To: nickgea...@gmail.com
To: Development Apache
Hello,
I took the tags parsing code from mod_headers to incorporate it to
mod_substitute.
It almost works, but I cannot obtain the handlers via apr_hash_get() -
even the locally defined ones (%D & %t).
They are all registered:
static int tags_pre_config(apr_pool_t *p, apr_pool_t *plog,
apr_pool_t *ptemp)
{
format_tag_hash = apr_hash_make(p);
register_format_tag_handler("D", (const void
*)tags_request_duration);
register_format_tag_handler("t", (const void *)tags_request_time);
register_format_tag_handler("e", (const void
*)tags_request_env_var);
register_format_tag_handler("s", (const void
*)tags_request_ssl_var);
return OK;
}
Any idea what could be the problem?
Btw, I copied the code from mod_headers and it is 98% identical, so I'll
modularise it to be 100% portable between these 2 modules (and others).
The next step will be to remove it from the modules itself and make the
static functions global.
Thanks,
Nick
Re: mod_substitute tags parsing
"%D" works, but, for instance, not "%{proxy-sendcl}e" which is set with
"setenv proxy-sendcl".
I call process_tags() in do_pattmatch() right after the initialisations.
This may be the cause?
Should I call it inside substitute_filter()?
I tried but I got the same result :-(
Nick
Original Message
Subject: Re: mod_substitute tags parsing
Date: Sun, 7 Nov 2010 13:48:47 +0100 (CET)
From: Stefan Fritsch
To: Development Apache , nickgea...@gmail.com
On Sun, 7 Nov 2010, Nick Gearls wrote:
Actually, the problem is that apr_table_get(r->subprocess_env, a) always
returns null.
I suppose that the problem lies in the request variable "r".
I am using f->r where f is the "ap_filter_t" given as parameter to
do_pattmatch().
Should I use another one,
No, that should be correct. This would mean that the envvar a that you are
asking for is not set. Which variable are you trying to use? If it is
provided by some module, it may be possible that it is only set later in
the request processing. Try a variable set with SetEnvIf.
Do the tags which don't lookup envvars, like %D, work?
Huge memory leak in mod_substitute
Hello, I saw servers completely freezing (the whole system, not only httpd) due to a memory leak problem in mod_substitute. This is a major issue as it can completely block your systems, sometimes even the fail-over as the server is blocked, but not completely down. Even the management interfaces are blocked. We reported the problem (https://issues.apache.org/bugzilla/show_bug.cgi?id=50559), with a (scaled-down) reproducible process to trigger it. Did somebody already begin to work on mod_substitute memory management? Regards, Nick
Re: Huge memory leak in mod_substitute
> we need to flatten and that takes time and space... lots o' space OK, but why more space at each request? The memory should be released at the end of the request. Nick On 7/1/2011 16:56, Jim Jagielski wrote: On Jan 7, 2011, at 10:46 AM, Nick Kew wrote: On Fri, 7 Jan 2011 15:59:26 +0100 "Plüm, Rüdiger, VF-Group" wrote: The obvious question would be whether the "q" flag affects your observations. But the detailed bug report suggests that's unlikely. Isn't it the case that "q" is the default for one substitution rule and for more than one it is no longer? That would explain the different behaviour. Bah. I'd misread Test 2 in the report - saw just the one rule. I guess it just boils down to the logic of when folding does or doesn't get optimised out. I think it's just the nature of the beast... at least, the nature of the design where if we need to be able to scan between buckets, we need to flatten and that takes time and space... lots o' space.
Re: Huge memory leak in mod_substitute
When setting the q flag, I have no more memory leaks. And it substitutes all instances on the line; however, it seems we cannot assume it will always do so :-( Btw, I never understood when multiple subst will work with the q flag; does somebody have an answer? For instance, Substitute s/aa/b/q works on "aa", even on a 10 KB long with "a". Thanks, Nick On 7/1/2011 15:49, Nick Kew wrote: On Fri, 07 Jan 2011 14:26:35 +0100 Nick Gearls wrote: Hello, I saw servers completely freezing (the whole system, not only httpd) due to a memory leak problem in mod_substitute. This is a major issue as it can completely block your systems, sometimes even the fail-over as the server is blocked, but not completely down. Even the management interfaces are blocked. We reported the problem (https://issues.apache.org/bugzilla/show_bug.cgi?id=50559), with a (scaled-down) reproducible process to trigger it. Did somebody already begin to work on mod_substitute memory management? The obvious question would be whether the "q" flag affects your observations. But the detailed bug report suggests that's unlikely. So the second obvious question: have you tried equivalent observations with mod_sed and/or mod_line_edit?
Re: Allow to set config variables in the config a.k.a. mod_define
Using the $ character can interact with core interpolation, but also
with, for instance, mod_macro.
I strongly recommend to let mod_define's ability to replace the special
characters.
Moreover, mod_define is very stable, so why to strip it instead of just
extending it?
Cheers,
Nick
Original Message
Subject: Allow to set config variables in the config a.k.a. mod_define
Date: Thu, 20 Jan 2011 12:01:19 +0100 (CET)
From: Stefan Fritsch
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
Hi,
mod_define's capability to define variables in the config is a really nice
to have feature and I have intended to integrate the module it into trunk.
But I have now noticed that core's environment interpolation of ${xxx} is
done before mod_define runs, and that it is not possible to override the
values of os envvars with mod_define. Therefore I now intend to integrate
a reduced variant of mod_define into core's ap_resolve_env. This also
makes it possible to add a command line option to define a variable.
I don't intend to include mod_define's ability to replace the special
characters ${...} with other characters. I don't think that is worth the
effort. Core will interpolate envvars with this syntax anyway.
Anyone disagrees?
Cheers,
Stefan
Re: Allow to set config variables in the config a.k.a. mod_define
Using extensively mod_define, mod_macro and rewrite maps in very big
environments, I personally chose for ~{...} to be safe.
But, as far as we can change it, everyone can choose what they want.
Regards,
Nick
Original Message
Subject: Re: Allow to set config variables in the config a.k.a. mod_define
Date: Thu, 20 Jan 2011 16:29:43 +0100
From: Rainer Jung
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
On 20.01.2011 16:02, Stefan Fritsch wrote:
On Thu, 20 Jan 2011, Nick Gearls wrote:
Using the $ character can interact with core interpolation, but also
with, for instance, mod_macro.
I strongly recommend to let mod_define's ability to replace the special
characters.
Moreover, mod_define is very stable, so why to strip it instead of
just extending it?
Sorry, I didn't make that clear in my original mail. It's very difficult
for a module to hook into the config processing early enough to be able
to override core's envvar interpolation. It's much easier to do that if
the functionality is in the core.
But conflicts with mod_macro and RewriteMaps are a valid concern. I will
try to include the ability to replace the special characters.
Do we want to change the default special chars? There are not many
reasonable combinations left that would not produce other clashes. Maybe
$( ) would be a possiblity.
If we stick strictly to ${XXX} then I don't see an immediate problem
with mod_macro, which should use plain $XXX. The syntax overlap with
rewrite maps should go away if variable names are not allowed to contain
a colon.
If this is correct, at least I would prefer sticking to ${XXX} and not
$(XXX).
Regards,
Rainer
Original Message
Subject: Allow to set config variables in the config a.k.a. mod_define
Date: Thu, 20 Jan 2011 12:01:19 +0100 (CET)
From: Stefan Fritsch
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
Hi,
mod_define's capability to define variables in the config is a really
nice
to have feature and I have intended to integrate the module it into
trunk.
But I have now noticed that core's environment interpolation of ${xxx} is
done before mod_define runs, and that it is not possible to override the
values of os envvars with mod_define. Therefore I now intend to integrate
a reduced variant of mod_define into core's ap_resolve_env. This also
makes it possible to add a command line option to define a variable.
I don't intend to include mod_define's ability to replace the special
characters ${...} with other characters. I don't think that is worth the
effort. Core will interpolate envvars with this syntax anyway.
Anyone disagrees?
Cheers,
Stefan
mod_reqtimeout logging
Hello, When an attack (timeout) is detected, it is logged at the info level. Shouldn't this be considered as a warning? Regards, Nick
Re: mod_reqtimeout logging
Probably not, but as we specify the time-outs to allow all normal requests (we hope), I'd like to be warned when an attack occurs, but also if one of my genuine customers is blocked (to possibly fine-tunes the time-outs). Another option would be to set an environment variable, so I could check it and handle my notification manually. On 9/2/2011 18:13, Eric Covener wrote: On Wed, Feb 9, 2011 at 10:28 AM, Nick Gearls wrote: Hello, When an attack (timeout) is detected, it is logged at the info level. Shouldn't this be considered as a warning? Can it know when one of the timeouts looks malicious vs. just being delayed?
Fwd: ProxyPreserveHost - added functionality
> ProxyPass /cgi-bin/ http://otherserver.com/cgi-bin/ preservehost=On > keepalive=Off > > This is more akin to how other worker properties are set. What when we use RewriteRule[P] to proxy instead of ProxyPass? For those who wonder why some may want to use RewriteRule, instead of ProxyPass: it is (maybe?) the only way to control the sequence of rewriting when you have several RewriteRule rules on top of the proxying one.
re: SSL related DoS
there doesn't seem to be any immediate demand for renegotiation > support, so it makes the most sense to leave it optional-to-enable > rather than optional-to-disable. If you want to protect some parts of your site with client authentication, then you need to enable insecure renegotiation to support (not so) old browsers - even latest version of Safari on Mac. But I agree it should stay disabled by default (most secure). And client-side renegotiation isn't probably needed as several app servers do not honour it any way. Nick
mod_proxy & headers
Hello, It seems that some headers cannot be modified when mod_proxy sets them. Ex: Content-Type - it is not possible to overwrite it with any of the following directives: AddType ... ForceType ... Header set ... I suppose that mod_proxy runs later then mod_headers 5?). Could this be clarified in the doc? As a general note, wouldn't it be possible to get, for each directive, the phase where it runs, to be able to understand processing order between modules? For the moment, the only ways are a look in the code or a test. Thanks Nick
Re: mod_proxy & headers
It's indeed prior to 2.2.12. I assume the problem is solved. However, what about the proposition to indicate for every module (or directive when needed) the phase it runs, to be able to determine interactions? I guess this shouldn't be difficult when you know the module. This could maybe even be generated automatically from the code? And maybe also specific features, like SetEnv result that cannot be used by other modules whereas SetEnvIf result can. This would be a major help in some cases. Regards, Nick Original Message Subject: RE: mod_proxy & headers Date: Mon, 2 May 2011 12:28:50 +0200 From: "Plüm, Rüdiger, VF-Group" Reply-To: dev@httpd.apache.org To: -Original Message- It seems that some headers cannot be modified when mod_proxy sets them. Ex: Content-Type - it is not possible to overwrite it with any of the following directives: AddType ... ForceType ... Header set ... Which version did you use where Header set Content-Type failed? It does not work correctly before 2.2.12.
Re: mod_proxy & headers
Nick, I understand the goal. But what about indicating for each module the "hook phase" it is using (first/middle/last). Probably only one entry for most modules. One entry fort some directives for complex ones. Would this be so complex to read? I agree it would probably be ignored by most readers, although the principle would be rather easy to understand. For the moment, I have the impression that simplicity takes precedence over exhaustiveness, no? Where else (apart from the code) could I find this information? If somebody has another idea how to compile it (like a separate table containing every module "hook phase"), that's also a solution. Would it be realistic to have a table with all modules "hook phase" (with several entries for some of them)? Regards, Nick On 2/5/2011 13:11, Nick Kew wrote: On Mon, 02 May 2011 12:56:10 +0200 Nick Gearls wrote: However, what about the proposition to indicate for every module (or directive when needed) the phase it runs, to be able to determine interactions? I guess this shouldn't be difficult when you know the module. This could maybe even be generated automatically from the code? No. In the first place, for many directives there's no simple answer. Secondly, the last thing our documentation needs is more confusing complexity. "Too complex" is already the most common objection to apache from users of corporate servers. To think it through, take a look at http://httpd.apache.org/docs/2.3/rewrite/tech.html#InternalAPI which does what you ask. If all our documentation starts to look like that, how many users will ever understand TFM? Of course, if you want to prove me wrong, start writing!
ProxyPass & ErrorDocument
Unless I misunderstand something, I found a problem with ProxyPass behaviour: with the config below, I expect, when the back-end server does not answer (status 502), to receive my custom HTML page. But it doesn't - the exception (ProxyPass "/local" !) is ignored. ErrorDocument 502 /local/unavailable.html ProxyPass "/local" ! ProxyPass "http://..."; Note that, when using , the correct custom page is displayed. Is this indeed a bug? Any work-around? Thanks, Nick
Bug #47066: environment variables in Header/RequestHeader
I'm using this patch (https://issues.apache.org/bugzilla/attachment.cgi?id=25643) in prod in several huge environments for more than one year and it rocks. Can we add this to trunk? Thanks, Nick
Re: Improving SSL config
Isn't it safer to only accept explicit entries, like SSLCipherSuite -ALL:RC4-SHA:AES128-SHA:TLSv1+HIGH:SSLv3+HIGH:-aNULL SSLProtocol-ALL +SSLv3 +TLSv1 Nick On 13/11/2011 11:47, Kaspar Brand wrote: On 07.10.2011 07:10, William A. Rowe Jr. wrote: Exactly... we should default to a server with a preference for cryptographic strength, but I have no objection to offering a commented-out, clearly documented 'alternative' configuration favoring performance, provided that is clearly labeled as 'not for sensitive data'. Now that the dust after the "BEAST" bang has settled somewhat (and it's clear that it needs to / will be fixed on the client side [1][2][3]), I think it's a good time to revisit the default setting for SSLCipherSuite - at least for trunk and 2.4. My proposal is something like the attached patch - thoughts, objections? Kaspar [1] https://bugzilla.mozilla.org/show_bug.cgi?id=665814 [2] http://codereview.chromium.org/7621002/ [3] http://my.opera.com/securitygroup/blog/2011/09/28/the-beast-ssl-tls-issue
mod_substitute buggy execution order
Directive execution order is performed in a very strange way in mod_substitute. Look at the following example: Substitute "s/aaa/global/inq" Substitute "s/aaa/local/inq" If I have "aaa" in a page, I expect it to be replaced by "global". No luck, it is replaced by "local". Even more crazy: Substitute "s/aaa/local1/inq" Substitute "s/aaa/local2/inq" Substitute "s/aaa/local3/inq" I expect the first directive to execute and see "local1". No luck again, it is replaced by "local2" - yes, not "local3". The merging of directive by Apache is performed in the following order: global, local1, local2, local3 but directives are executed in the following order: : local2, local3, local1, global Am I confused or should we fix that? Thanks, Nick
Fwd: mod_substitute buggy execution order
That's very different from other modules.
Most (all?) modules do the opposite: first global, then local - ex: rewrite
Furthermore, narrowing does not work the way you expect as
Substitute "s/aaa/local1/inq"
Substitute "s/aaa/local2/inq"
Substitute "s/aaa/local3/inq"
will end up with "local2" which is not the narrowest-scope.
I understand your concern, but this definitely breaks the usual way of
working which thus introduces an inconsistency with other modules .
mod_substitute is gone from 2.4
Is it replaced by mod_sed? What is the logic there?
Thanks,
Nick
Original Message
Subject:Re: mod_substitute buggy execution order
Date: Mon, 19 Dec 2011 15:34:41 -0600
From: William A. Rowe Jr.
To: dev@httpd.apache.org
CC: Nick Gearls
On 12/19/2011 8:40 AM, Nick Gearls wrote:
Directive execution order is performed in a very strange way in mod_substitute.
Look at the following example:
Substitute "s/aaa/global/inq"
Substitute "s/aaa/local/inq"
If I have "aaa" in a page, I expect it to be replaced by "global".
No luck, it is replaced by "local".
Not a bug. {global} is broader scope than /test/ URI. Therefore the
server is performing the narrowest-scope replacements, first.
Otherwise, there would be no way to fine-tune the results in more
narrow contexts!
Even more crazy:
Substitute "s/aaa/local1/inq"
Substitute "s/aaa/local2/inq"
Substitute "s/aaa/local3/inq"
I expect the first directive to execute and see "local1".
No luck again, it is replaced by "local2" - yes, not "local3".
The merging of directive by Apache is performed in the following order:
global, local1,
local2, local3
but directives are executed in the following order: : local2, local3, local1,
global
Am I confused or should we fix that?
I think this is fine. It certainly should be documented, and we could
process replacements in last-to-first order within the same scope, but
I'm not sure that makes a huge difference (and would be inappropriate
to change this late in 2.2). Since mod_substitute is gone from 2.4, I
doubt there is really an opportunity to change this anymore.
Additional info in build
Hello, When dealing with config running on different platforms (ex: Linux/Solaris/Windows, 32/64 bits), it is very difficult to write a generic config because some dependencies are platform-specific. Ex: - LoadFile /lib64/libgcc_s.so.1 - LoadFile /lib/libgcc_s.so.1 Couldn't we add some defines in the build to identify (at least) the OS and 32/64 bits, like -D OS_UNIX / OS_WINDOWS -D OS_32 / OS_64 -D OS_LINUX / OS_FREEBSD / OS_SOLARIS -D OS_LINUX_REDHAT / OS_LINUX_UBUNTU / ... (?) This would allow the following generic config: LoadFile /usr/lib/libxml2.so.2 LoadFile /usr/lib64/libxml2.so.2 Regards, Nick
httpd 3
Hello, It was requested to provide some ideas for the direction to go with httpd 3. One of the main issues I'd like to be tackled is the lack of consistency in the directives for linked functionalities. For instance: - Some modules have access to variables set with Setenv, but not those set with SetenvIf (and the opposite) - Setenv & SetenvIf are not processed sequentially (first all Setenv, then all SetenvIf) - SetenvIf can overwrite a variable (set with SetenvIf ) inside a location, but Setenv cannot - Every module is using its own tag parsing to access environment variables (and request info). This is not only redundant, but - variable expansion is not available in some modules - the syntax is not always the same - all variables are not available in all modules (ex: SSL variables are not always available) - Filters set with AddOutputFilterByType are not removed with RemoveOutputFilter - Modules using outgoing connections (ex: OCSP requests in mod_ssl) do not benefit from the pooling features available in mod_proxy - RewriteRule[P] can be used instead of ProxyPass but ProxyPass directives are executed first, even if a RewriteRule appears first - etc. In a general way, there is absolutely no info about this lack of consistency and, every time a question is asked, developers have more or less to guess the answer (by looking at the code I guess). Could this problem be solved by - centralizing some functionalities and generalizing some mechanisms - formalize the way to use them - defining a directive processing order based on the functionality instead of the module - and DOCUMENT all of this This would really be a huge benefit for advanced use of httpd. Thanks, Nick
Inserting a request in the middle of another one
Hello, I'd like to insert a request in the middle of another one. Example: request --> httpd(proxy mode) -> web site should become request --> httpd(receive) --> external request --> httpd(send) -> web site I obviously need to send my external request based on the received request and modify it before proxying it based on the output of my external request - otherwise it would be too simple ;-) What would be the best approach? I can write a module to send an external HTTP request, that's not a big issue. I can get all info from the originating request in httpd structures, that's rather easy. However, do I have any facilities to send/receive the HTTP external request? I can send it with bare buckets, but I would need manually parse the result; this would be heavy. Is there any easier way (like using mod_proxy) to get some higher level access to the result headers (for instance)? Thanks Nick
Re: mod_macro into apache ?
On 11-11-2012 18:16, Stefan Fritsch wrote: On Sunday 11 November 2012, Rainer Jung wrote: I would like to donate the code so that it could be integrated with apache as a standard module. +1 +1 +1
Re: 3 questions about inclusion of mod_macro into apache
On 04-12-2012 18:04, fab...@apache.org wrote: Without UndefMacro, it can lead to warnings on redefinitions that could be considered noisy and could not be removed. I agree
Re: [VOTE] accept mod_macro as standard module in httpd
+1 On 03-01-2013 03:06, Eric Covener wrote: I was preparing the IP clearance forms and noticed our original "vote" thread was more of a discussion. I wanted to record a formal vote here so I can link to it. Pending IP clearance... [+1] accept mod_macro as a standard module and responsibility for its maintenance [ +/- 0] don't care won't help [ -1] don't accept mod_macro as a standard module My +1 -- Eric Covener cove...@gmail.com
HTTP headers management documentation
Couldn't we add, in the documentation: - a list of headers that cannot be added by mod_headers - a list of headers that are stripped by mod_proxy (and mod_proxy_*) I'm facing a practical case where it's a nightmare to find a correct solution, even with (very contradicting) information found at several places: proxying upgrade requests from http(s) to ws(s). There is no place where it is documented when (in which modules) the Connection & Upgrade request headers are discarded. There's also no indication that these request headers cannot set/added/appended. This kind of information would be invaluable for a lot of people. I would be happy to help with the documentation obviously, but I'm not very knowledgeable about this. Thanks
SIGSEGV, Segmentation fault
Hello, I'm using the Redhat 8 distribution (httpd 2.4.46) and I have a segmentation fault in mod_proxy_http.c. How can I work on this? Can I open a bug on bugzilla for a Redhat build? It does not happen for all requests, just some (and it's reproducible). Is it possible to deduce the problem from the following stack trace? Thread 3 "httpd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffda59e700 (LWP 3202)] ap_proxy_http_prefetch (url=0x7fffcc325dc0 "/webportalapi/v4/packages", uri=0x7fffcc325c80, req=0x7fffcc325ce0) at mod_proxy_http.c:640 640 origin->keepalive = AP_CONN_CLOSE; (gdb) bt #0 ap_proxy_http_prefetch (url=0x7fffcc325dc0 "/webportalapi/v4/packages", uri=0x7fffcc325c80, req=0x7fffcc325ce0) at mod_proxy_http.c:640 #1 proxy_http_handler (r=0x7fffcc011840, worker=, conf=, url=0x7fffd8492a6e "http://127.0.0.1/webportalapi/v4/packages";, proxyname=, proxyport=) at mod_proxy_http.c:2076 #2 0x7fffeeb84094 in proxy_run_scheme_handler (r=r@entry=0x7fffcc011840, worker=0xf8139920, conf=conf@entry=0xf8139778, url=0x7fffd8492a6e "http://127.0.0.1/webportalapi/v4/packages";, proxyhost=proxyhost@entry=0x0, proxyport=proxyport@entry=0) at mod_proxy.c:3102 #3 0x7fffeeb84e49 in proxy_handler (r=0x7fffcc011840) at mod_proxy.c:1266 #4 0x5559cad8 in ap_run_handler (r=r@entry=0x7fffcc011840) at config.c:170 #5 0x5559d096 in ap_invoke_handler (r=r@entry=0x7fffcc011840) at config.c:444 #6 0x555b4243 in ap_process_async_request (r=r@entry=0x7fffcc011840) at http_request.c:453 #7 0x555b43b2 in ap_process_request (r=r@entry=0x7fffcc011840) at http_request.c:488 #8 0x555b05d5 in ap_process_http_sync_connection (c=0x7fffd4003c68) at http_core.c:210 #9 ap_process_http_connection (c=0x7fffd4003c68) at http_core.c:251 #10 0x555a6ab8 in ap_run_process_connection (c=c@entry=0x7fffd4003c68) at connection.c:42 #11 0x555a7038 in ap_process_connection (c=c@entry=0x7fffd4003c68, csd=csd@entry=0x7fffd4003a50) at connection.c:219 #12 0x7392b41f in process_socket (bucket_alloc=0x7fffcc000b88, my_thread_num=0, my_child_num=0, sock=0x7fffd4003a50, p=0x7fffd40039d8, thd=0x566286a0) at worker.c:479 #13 worker_thread (thd=0x566286a0, dummy=) at worker.c:808 #14 0x76b0a14a in start_thread (arg=) at pthread_create.c:479 #15 0x76635dc3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thanks a lot
Define variable in modules
Hello, It would sometimes be very handy to be able to define a variable (like -D on command-line or "Define xxx" in the config) inside a module. This would, for instance, allow to have a config file based on a define from the module, knowing if the new syntax is known or not, etc. Concrete example: in mod_security2, they introduced a new "collection". If you use this collection in an old version, it's a syntax error. If mod_security2 defines the variable "support_new_collection" (OK, very bad name obviously), then we can enclose the rule using a ". Would it be possible to export a function to define such a variable? Thanks
Re: Define variable in modules
Technically, it would work, and I actually did it in my own modules. But I'm afraid some people (at ModSecurity or in other modules) won't accept to misuse a feature :-( On 20-10-2022 20:35, Christophe JAILLET wrote: Le 20/10/2022 à 15:55, Nick Gearls a écrit : Hello, It would sometimes be very handy to be able to define a variable (like -D on command-line or "Define xxx" in the config) inside a module. This would, for instance, allow to have a config file based on a define from the module, knowing if the new syntax is known or not, etc. Concrete example: in mod_security2, they introduced a new "collection". If you use this collection in an old version, it's a syntax error. If mod_security2 defines the variable "support_new_collection" (OK, very bad name obviously), then we can enclose the rule using a ". Would it be possible to export a function to define such a variable? Thanks Hi, Maybe this would not be super-clean, but the module could define some (useless) directives (i.e. MOD_SEC2_HAS_NEW_COLLECTION_SUPPORT) and config files could be tweaked with . This should work as-is without any new code. Does it match your use-case? CJ
mod_substitute debugging
I added some debugging features in mod_substitute, damned useful when trying to troubleshoot things. I'll propose a patch but I'd like your advise about when to log debug info: I added the following info: 1. line to be parsed, type or search (regex/string), replace string 2. in case of matching, the new value All logging of debugging info is in level TRACE8 Remark: the matching string/regex is compiled, so it's not available at run-time. I added this info in the subst_pattern_t struct - with a #ifdef _DEBUG to not waste memory in release mode My main question is: do I leave all logging in release mode (TRACE8 level) or do I also make this logging dependent on the compile flag? Nick
Re: mod_substitute debugging
Hi Ruediger, I understood that. My main question was "Which code do I include and release version and which one do I keep only for a debug build?" I have no problem to have everything included with a run-time check, I was just wondering if someone will not complain that this adds too much things. I'll prepare a patch to have everything included at run-time, we'll see the feedback. Thanks for your time On 24-05-2017 16:17, Ruediger Pluem wrote: On 05/24/2017 03:56 PM, Nick Gearls wrote: I added some debugging features in mod_substitute, damned useful when trying to troubleshoot things. I'll propose a patch but I'd like your advise about when to log debug info: I added the following info: 1. line to be parsed, type or search (regex/string), replace string 2. in case of matching, the new value All logging of debugging info is in level TRACE8 Remark: the matching string/regex is compiled, so it's not available at run-time. I added this info in the subst_pattern_t struct - with a #ifdef _DEBUG to not waste memory in release mode My main question is: do I leave all logging in release mode (TRACE8 level) or do I also make this logging dependent on the compile flag? Neither :-). Have a look at the APLOG_*_IS_LEVEL macros in http_log.h and wrap the code that creates effort accordingly. If the effort is just a simple ap_log_?error line then you need to nothing if compiled with a c99 compiler. See the ap_log_* macro magic in http_log.h Regards Rüdiger
Re: mod_substitute debugging
Patch uploaded: https://bz.apache.org/bugzilla/show_bug.cgi?id=61132 On 30-05-2017 09:00, Nick Gearls wrote: Hi Ruediger, I understood that. My main question was "Which code do I include and release version and which one do I keep only for a debug build?" I have no problem to have everything included with a run-time check, I was just wondering if someone will not complain that this adds too much things. I'll prepare a patch to have everything included at run-time, we'll see the feedback. Thanks for your time On 24-05-2017 16:17, Ruediger Pluem wrote: On 05/24/2017 03:56 PM, Nick Gearls wrote: I added some debugging features in mod_substitute, damned useful when trying to troubleshoot things. I'll propose a patch but I'd like your advise about when to log debug info: I added the following info: 1. line to be parsed, type or search (regex/string), replace string 2. in case of matching, the new value All logging of debugging info is in level TRACE8 Remark: the matching string/regex is compiled, so it's not available at run-time. I added this info in the subst_pattern_t struct - with a #ifdef _DEBUG to not waste memory in release mode My main question is: do I leave all logging in release mode (TRACE8 level) or do I also make this logging dependent on the compile flag? Neither :-). Have a look at the APLOG_*_IS_LEVEL macros in http_log.h and wrap the code that creates effort accordingly. If the effort is just a simple ap_log_?error line then you need to nothing if compiled with a c99 compiler. See the ap_log_* macro magic in http_log.h Regards Rüdiger
Re: SSLPolicy
This can be done using mod_macro without any additional code On 04-08-2017 11:26, Stefan Eissing wrote: I talked about some kind of SSL Policy definition in httpd's configuration in the past and am now about to get serious about it. Here is what I wan to do: Recap: the general idea is 1. Give a set of SSL directives a name and allow the user to apply that name in several virtual hosts. 2. Provide a set of already defined policies that either follow a public definition (like the Mozilla security classes) or express our idea of how configuration should look like. 3. Allow distributions/users to define their own policy sets, of course. The Benefits I'd like to achieve with this: A. A name makes it easier to talk about used/recommended configurations. It also makes it easy for admins to apply a known set of policies. It is less error prone. B. SSLPolicy definitions can be updated by us or by distributions, since the config defining the policies need not be edited by the user, e.g. can be replaced in an update. This way, a broken cipher/protocol can be updated away in policies we/distributions define. This should help increase security of https on the internet. The proposal: Introduce two new directives "SSLPolicy" and " SSLProtocol ... SSLCipherSuite ... ... defines a set of SSL configuration directives (basically all non-proxy that are applicable in vhosts). This can only be done in the global context. Names may not be overwritten. SSLPolicy name applies the policy in the given context (server/vhost). Implementation: Changes should basically only affect ssl_kernel_config.c. Config commands will add a check if they are inside a "
Potential output filter order of processing
Hello, I encounter a problem with the order of processing of output filters. Maybe I'm missing some background but there's something very weird. I'll show the example with mod_substitute but I imagine it's similar for other modules (although I'm not sure). Case 1: Subst "s/x/1x/qn" Subst "s/x/2x/qn" Result: 'x' is replaced by '12x' (seems logical) Case 2: Subst "s/x/1x/qn" Subst "s/x/2x/qn" Result: 'x' is replaced by '12x' (seems logical) Case 3: Subst "s/x/1x/qn" Subst "s/x/2x/qn" Result: 'x' is replaced by '21x' ?!? Apache is supposed to execute location from top to bottom, no? So why does it parse them the other way around in this case? The filter is defined as AP_FTYPE_RESOURCE; does this impact the order of processing locations? Thanks for any hint
Re: Unexpected Warnings from Macro Use in 2.4
Wrong answer: mod_macro uses the syntax $var but also ${var}, which is
mandatory if you want the variable to be a part of a string, like in
"${var}abc".
The syntax really clashes with the Define directive, so it should be
changed.
Another unused character could be used, like §
On 18-02-2015 19:53, Gregg Smith wrote:
On 2/18/2015 6:12 AM, Tom Browder wrote:
I have been using mod_macro for some time and always get the following
types of messages on startup (using 2.4.12 now, but this behavior has
been noticed since 2.4.7):
[Wed Feb 18 13:54:55.019032 2015] [core:warn] [pid 970:tid
140069833443200] AH00111: Config variable ${PROJECT} is not defined
[Wed Feb 18 13:54:55.019041 2015] [core:warn] [pid 970:tid
140069833443200] AH00111: Config variable ${TLD} is not defined
For the example httpd instance only one macro is defined, used, and
undefined like this:
ServerName ${PROJECT}.${TLD}
ServerAlias www.${PROJECT}.${TLD}
DocumentRoot /home/web-sites/${PROJECT}.${TLD}/public
Use VHOST_NONTLS mysite org
UndefMacro VHOST_NONTLS
The warnings I believe are spurious and should not be there. The
virtual hosts work fine after startup. Apparently, the first time
though the macro definitions are read and, since they are not defined,
the warnings are produced. It seems to me that is a bug.
Am I doing something wrong?
Probably because ${VAR} is used when defining variables in the config,
like ServerRoot is.
http://httpd.apache.org/docs/2.4/mod/core.html#define
mod_macro uses just $var so just remove the braces in your above example.
http://httpd.apache.org/docs/2.4/mod/mod_macro.html
Re: Unexpected Warnings from Macro Use in 2.4
“${macro:var}” is a good option
+1
On 19-02-2015 21:08, Tim Bannister wrote:
On 19 Feb 2015, at 13:02, Nick Gearls wrote:
Wrong answer: mod_macro uses the syntax $var but also ${var}, which is mandatory if you
want the variable to be a part of a string, like in "${var}abc".
The syntax really clashes with the Define directive, so it should be changed.
Another unused character could be used, like §
There aren't many suitable symbols left unused.
To make interpolation not clash with Define I'd prefer “${macro:var}”, or
something like that, to “§{var}”.
Re: Unexpected Warnings from Macro Use in 2.4
You could define, by mistake, the as wi Define & Macro, then, what will
happen ...
On 20-02-2015 15:09, Tom Browder wrote:
On Thu, Feb 19, 2015 at 2:08 PM, Tim Bannister wrote:
On 19 Feb 2015, at 13:02, Nick Gearls wrote:
Wrong answer: mod_macro uses the syntax $var but also ${var}, which is mandatory if you
want the variable to be a part of a string, like in "${var}abc".
The syntax really clashes with the Define directive, so it should be changed.
Another unused character could be used, like §
There aren't many suitable symbols left unused.
To make interpolation not clash with Define I'd prefer “${macro:var}”, or
something like that, to “§{var}”.
Since there is a clash with Define why not '@{var}'?
But I still wonder why the need? Since it works somehow, can't you
just fix the parse warningin the macro definition? (I took a cursory
look at the code, and I'm again overwhelmed--will take some time to
get familiar with it for me.)
Best regards,
-Tom
Re: Unexpected Warnings from Macro Use in 2.4
Define mysite www.mycompany.com
Servername${mysite}
ErrorLog /var/log/httpd/${mysite}_error.log
Use NewSite www.company1.com
Use NewSite www.company2.com
Obviously, you expect this to be done in different files modified by
different people
On 23-02-2015 14:52, Tom Browder wrote:
On Feb 23, 2015 6:38 AM, "Nick Gearls" wrote:
You could define, by mistake, the same with Define & Macro, then, what will
happen ...
Can you be more specific, please?
Bug 57641
Hi all, Can anybody have a look at this trivial bug waiting for months? The bug is obvious and the fix is a one line change. Thanks a lot
Fwd: Unexpected Warnings from Macro Use in 2.4
This is definitely a bug as we have a major incompatibility between two
features.
Remark: although mod_macro can use $ and % for unescaped characters,
${x} is used by Define and %{x} by mod_rewrite :-(
I suppose the preferred solution to not be incompatible with the current
situation would be an optional directive to overwrite the $ character
(DefineChar?)
Forwarded Message
Subject:Re: Unexpected Warnings from Macro Use in 2.4
Date: Sat, 22 Aug 2015 11:16:44 -0500
From: Tom Browder
To: nickgea...@gmail.com, dev@httpd.apache.org
On Tue, Feb 24, 2015 at 7:15 AM, Tom Browder wrote:
On Feb 24, 2015 6:52 AM, "Nick Gearls" wrote:
Define mysite www.mycompany.com
Servername${mysite}
ErrorLog /var/log/httpd/${mysite}_error.log
Use NewSite www.company1.com
Use NewSite www.company2.com
That's similar to the way I use it for multiple virtual hosts and have no
problems except the warnings I reported.
The problem still exists in 2.4.16. Shall I file a bug?
-Tom
mod_macro: Control on bad nesting
mod_macro checks that nesting is complete inside a macro. This looks a good default, however there are some cases where we want this and it generates a warning for nothing. Ex: ServerName @name ... I'd like to add an option to suppress this warning when we need it. The simplest option I see would be to add something on the macro definition line itself. Because we may need some other options later, I guess a "flag" would be the most generic approach. What syntax would be the best one? maybe a (one character) /option after the Macro keyword? Ex: "" (and later "Added a feature request on https://bz.apache.org/bugzilla/show_bug.cgi?id=59660
Re: mod_macro: Control on bad nesting
Good point. A global option is not a good option as it would disable this very useful check for all macros. What about " wrote: What syntax would be the best one? maybe a (one character) /option after the Macro keyword? Ex: "" (and later " Kinda ugly and probably breaks the core from recognizing " (bad name) that is a very thin wrapper around existing stuff?
Re: mod_macro: Control on bad nesting
There's a patch (see https://bz.apache.org/bugzilla/show_bug.cgi?id=59660) containing both options (global directive + flag) for both warnings (nesting & empty arguments) Good point. A global option is not a good option as it would disable this very useful check for all macros. What about " wrote: > What syntax would be the best one? maybe a (one character) /option after the > Macro keyword? > Ex: "" (and later " (bad name) that is a very thin wrapper around existing stuff?
Re: Unexpected Warnings from Macro Use in 2.4
There's a patch (see
https://bz.apache.org/bugzilla/show_bug.cgi?id=58304) adding a warning
in case of syntax clash with 'Define'
On 2/18/2015 6:12 AM, Tom Browder wrote:
> I have been using mod_macro for some time and always get the following
> types of messages on startup (using 2.4.12 now, but this behavior has
> been noticed since 2.4.7):
>
> [Wed Feb 18 13:54:55.019032 2015] [core:warn] [pid 970:tid
> 140069833443200] AH00111: Config variable ${PROJECT} is not defined
> [Wed Feb 18 13:54:55.019041 2015] [core:warn] [pid 970:tid
> 140069833443200] AH00111: Config variable ${TLD} is not defined
>
> For the example httpd instance only one macro is defined, used, and
> undefined like this:
>
>
>
> ServerName ${PROJECT}.${TLD}
> ServerAlias www.${PROJECT}.${TLD}
> DocumentRoot /home/web-sites/${PROJECT}.${TLD}/public
>
>
> Use VHOST_NONTLS mysite org
> UndefMacro VHOST_NONTLS
>
> The warnings I believe are spurious and should not be there. The
> virtual hosts work fine after startup. Apparently, the first time
> though the macro definitions are read and, since they are not defined,
> the warnings are produced. It seems to me that is a bug.
>
> Am I doing something wrong?
Re: Unexpected Warnings from Macro Use in 2.4
Nobody is interested in avoiding problems with this sanity check?
Trivial to review, only a warning - but that could save hours to users
On 06-07-2016 09:25, Nick Gearls wrote:
There's a patch (see
https://bz.apache.org/bugzilla/show_bug.cgi?id=58304) adding a warning
in case of syntax clash with 'Define'
On 2/18/2015 6:12 AM, Tom Browder wrote:
> I have been using mod_macro for some time and always get the following
> types of messages on startup (using 2.4.12 now, but this behavior has
> been noticed since 2.4.7):
>
> [Wed Feb 18 13:54:55.019032 2015] [core:warn] [pid 970:tid
> 140069833443200] AH00111: Config variable ${PROJECT} is not defined
> [Wed Feb 18 13:54:55.019041 2015] [core:warn] [pid 970:tid
> 140069833443200] AH00111: Config variable ${TLD} is not defined
>
> For the example httpd instance only one macro is defined, used, and
> undefined like this:
>
>
>
> ServerName ${PROJECT}.${TLD}
> ServerAlias www.${PROJECT}.${TLD}
> DocumentRoot /home/web-sites/${PROJECT}.${TLD}/public
>
>
> Use VHOST_NONTLS mysite org
> UndefMacro VHOST_NONTLS
>
> The warnings I believe are spurious and should not be there. The
> virtual hosts work fine after startup. Apparently, the first time
> though the macro definitions are read and, since they are not defined,
> the warnings are produced. It seems to me that is a bug.
>
> Am I doing something wrong?
Re: mod_macro: Control on bad nesting
The proposed patch (https://bz.apache.org/bugzilla/attachment.cgi?id=34012&action=diff) is fully back-ward compatible and can save a lot of useless warnings in the log. Anyway to get somebody review it? Thanks On 06-07-2016 09:20, Nick Gearls wrote: There's a patch (see https://bz.apache.org/bugzilla/show_bug.cgi?id=59660) containing both options (global directive + flag) for both warnings (nesting & empty arguments) Good point. A global option is not a good option as it would disable this very useful check for all macros. What about "On Fri, 3 Jun 2016 10:19:24 -0400, Eric Covener wrote: > What syntax would be the best one? maybe a (one character) /option after the > Macro keyword? > Ex: "" (and later " (bad name) that is a very thin wrapper around existing stuff?
Re: mod_macro: Control on bad nesting
BOOL - fixed :-( Forwarded Message Subject:Re: mod_macro: Control on bad nesting Date: Wed, 5 Oct 2016 09:54:43 -0400 From: Jim Jagielski To: dev@httpd.apache.org, nickgea...@gmail.com 'bool' ?? On Oct 5, 2016, at 8:50 AM, Nick Gearls wrote: The proposed patch (https://bz.apache.org/bugzilla/attachment.cgi?id=34012&action=diff) is fully back-ward compatible and can save a lot of useless warnings in the log. Anyway to get somebody review it? Thanks On 06-07-2016 09:20, Nick Gearls wrote: There's a patch (see https://bz.apache.org/bugzilla/show_bug.cgi?id=59660) containing both options (global directive + flag) for both warnings (nesting & empty arguments) Good point. A global option is not a good option as it would disable this very useful check for all macros. What about " wrote: > What syntax would be the best one? maybe a (one character) /option after the > Macro keyword? > Ex: "" (and later " (bad name) that is a very thin wrapper around existing stuff?
Re: Unexpected Warnings from Macro Use in 2.4
I don't think mod_macro should emit a warning for its own basic configuration That's what it currently does (in 2.4) it happens to overlap with the cores variable expansion That's indeed a bad choice - this is why I propose a warning Forwarded Message Subject:Re: Unexpected Warnings from Macro Use in 2.4 Date: Wed, 5 Oct 2016 09:57:31 -0400 From: Eric Covener To: Apache HTTP Server Development List , nickgea...@gmail.com On Wed, Oct 5, 2016 at 8:48 AM, Nick Gearls wrote: Nobody is interested in avoiding problems with this sanity check? Trivial to review, only a warning - but that could save hours to users I didn't see it the first time, but I don't think mod_macro should emit a warning for its own basic configuration because it happens to overlap with the cores variable expansion. I don't like it for 2.4.
Re: Unexpected Warnings from Macro Use in 2.4
All syntax checks are done inside mod_macro. I agree that changing the syntax would be cleaner, but that would probably take some time. Until that, a warning is better than nothing, no? We could also raise the warning to an error but I suppose some peopel may complain about backward compatibility... On Thu, 6 Oct 2016 10:06:22, Eric Covener wrote On Thu, Oct 6, 2016 at 3:04 AM, Nick Gearls wrote: >> I don't think mod_macro should emit a warning for its own basic >> configuration > > That's what it currently does (in 2.4) Isn't it the core currently and not mod_macro? Which is why my preference is to advocate a syntax that isn't ambiguous/clashy (this might be more than a docs change, from my recollection of the last discussion about which of the supported syntaxes was least harmless/confusing)
Re: Interpolating %{variables} in all directives
Consistency would be a major enhancement. the best solution would be to
have it enabled without any change to current modules implementation.
Yes, it would be incompatible with the modules that implemented their
own parsing, but why not establish a new standard for httpd 3?
For 2.x, a trade-off could be found. I am partisan to allow the admin to
register the modules to exclude from the parsing (like rewrite, etc.)
On 18-04-2013 17:33, Daniel Gruno wrote:
On 04/18/2013 05:09 PM, Igor Galić wrote:
Hey folks o/~
From an IRC conversation in #httpd and #httpd-dev emerged the
idea to interpolate %{variables} in all directives.
According to sf we have somewhere a ~10 line code fragment
which does that without much overhead (not benchmarked) when
interpolating and with hardly any (short-circuit) when not.
I think it would be a good idea to allow for this to be used
in all directives (across all modules) it makes for immensly
more readable configurations because:
Example:
# default vhost redirecting every HTTP vhost to HTTPS:
Redirect / https://%{HTTP_HOST}/
Another example might be something "more advanced" like:
# group specific authorization:
[^/]+).*">
Require group %{group}
I'm for interpolating in as many places as makes sense, but I'm probably
not for interpolating verywhere at once, since that could lead to
clashes and unwanted results. Interpolation should be enabled in each
module that wants to use this, and not via a blanket config change (this
probably isn't viable/possible anyway), but I'm definitely for using it
in areas such as Redirect*, Location*, Header* and possibly Require
(although that one might be a tad difficult and would have to be
implemented locally in each individual auth module I suspect).
So, +1 to the general idea, but I think it would/should be enabled
'manually' in each module, and not some attempt to just make it all
switch at once. Perhaps we could start with Redirect*?
With regards,
Daniel.
.
Re: Interpolating %{variables} in all directives
On 23-04-2013 19:40, Vincent Deffontaines wrote: Last point, who knows, maybe using interpolation together with mod_macro/mod_rewrite will be the next great thing that we didn't think of, and this config will even let super clever admins invent it for us;) especially mod_define
Re: Add generic interface to derive cluster-wide secrets?
We should use a HMAC, not a hash - this is no secure secret
On 01-09-2013 14:04, Stefan Fritsch wrote:
Hi,
would it make sense to have a generic way to generate server secrets
that need to be the same on every server in a load-balanced cluster? I
thought of something like: The user configures one secret key file and
every module that needs a secret can then get a secret derived from
that key. As algorithm to derive the secret I thought of
sha256("module specific string" "secret key"). The "secret key"
should not be a password but be at least 256 bits of real random data.
If we want to allow passwords, the derivation function would need to
be more complex.
This could be used for example in mod_auth_digest and mod_ssl's
SRPUnknownUserSeed. If we add an interface to mod_lua, I am sure that
people would find more uses for it. I don't think that it would be
suitable for ssl session ticket keys, though, because those should be
rotated frequently.
Thoughts, comments?
Stefan
Re: mod_ssl and pkcs11
Maybe it's time to remove all redundant code in mod_ssl and use all features of OpenSSL; PKCS#11 will then be automatically supported and the maintenance of mod_ssl will be simplified a lot. On 26-11-2013 18:55, Kaspar Brand wrote: On 26.11.2013 16:44, Graham Leggett wrote: Hi all, I am trying to use a pkcs11 engine within mod_ssl, and am digging as to how this might be done. The closest I've found is this patch https://issues.apache.org/bugzilla/show_bug.cgi?id=52473 Anyone know if there is anything newer out there? I don't know, but perhaps https://issues.apache.org/bugzilla/show_bug.cgi?id=42688 is a better starting point than PR 52473 (which is based on PR 42687, from looking at its description). Kaspar
Re: LocationMatch (and friends) and back references
Why not using the standard regex syntax:
foo|bar)/baz/(?.*)">
On 26-12-2013 08:43, Graham Leggett wrote:
Hi all,
It seems it is currently not possible to make reference to backreferences in
regexes:
Something ${1}
One of the tricky things to overcome to make this possible is that multiple
LocationMatch'es might match, which makes the traditional ${1} pattern tricky
to implement internally, as ${1} might be shadowed by another LocationMatch. As
a possible solution to this, we could pass explicit variable names after the
regex which are then populated into the subprocess environment and can be
referenced elsewhere:
Something ${MATCH_MYPREFIX}
SomethingElse ${MATCH_MYFILE}
Naming the backreferences explicitly has the advantageous side effect that we
know how many of them there are (or we care about) and can pass or not pass the
correct sized array to ap_regexec() as needed, meaning that supporting
backreferences needs no performance penalty for people who don't use them.
Obviously the making the subprocess environment available to directives is a
separate issue.
Thoughts?
Regards,
Graham
--
FakeBasicAuth changes
Did something change in 2.2.6 regarding FakeBasicAuth ? I always get now 'user /...: authentication failure for "/path/": Password Mismatch'. It worked with version 2.0.59, with the same config (see below). Does 2.2.6 it use another hash algorithm by default or so ? In the debug log, I can find: Faking HTTP Basic Auth header: "Authorization: Basic L0M9QkUvU1Q9QmVsZ2l1bS9MPUJydXNzZWxzL089QXBwcm9hY2ggQmVsZ2l1bS9PVT1BcGFjaGUgdGVzdCBjZXJ0aWZpY2F0ZS9DTj0xMjcuMC4wLjE6cGFzc3dvcmQ=" What is this header contents ? Isn't it supposed to be base64 ? I cannot decode it. Thanks Nick SSLVerifyClient require SSLRequireSSL SSLOptions +FakeBasicAuth Authname "NSA protected site for countries" AuthType Basic AuthUserFile conf/users.auth Require valid-user user.auth (DN coming from OpenSSL): /...:xxj31ZMTZzkVA
Re: FakeBasicAuth changes
My Base64 decoder did not decode it :-( Anyway, I always get 'user /...: authentication failure for "/path/": Password Mismatch', although my password file looks correct: /C=BE/ST=Belgium/L=Brussels/O=Approach Belgium/OU=Apache test certificate/CN=127.0.0.1:xxj31ZMTZzkVA Does 2.2.6 it use another hash algorithm by default or so ? For info, I use SSLVerifyClient require SSLRequireSSL SSLOptions +FakeBasicAuth Authname "NSA protected site for countries" AuthType Basic AuthUserFile conf/users.auth Require valid-user Henrik Nordstrom wrote: On ons, 2007-09-26 at 18:06 +0200, Nick Gearls wrote: In the debug log, I can find: Faking HTTP Basic Auth header: "Authorization: Basic L0M9QkUvU1Q9QmVsZ2l1bS9MPUJydXNzZWxzL089QXBwcm9hY2ggQmVsZ2l1bS9PVT1BcGFjaGUgdGVzdCBjZXJ0aWZpY2F0ZS9DTj0xMjcuMC4wLjE6cGFzc3dvcmQ=" What is this header contents ? Isn't it supposed to be base64 ? I cannot decode it. It's base64. Decoding it gives "/C=BE/ST=Belgium/L=Brussels/O=Approach Belgium/OU=Apache test certificate/CN=127.0.0.1:password" Regards Henrik
Re: FakeBasicAuth changes
I tried both MD5 and SHA-1.
I'm on Windows XP/2003.
Ruediger Pluem wrote:
On 09/26/2007 05:58 PM, Nick Gearls wrote:
My Base64 decoder did not decode it :-(
Anyway, I always get 'user /...: authentication failure for "/path/":
Password Mismatch', although my password file looks correct:
/C=BE/ST=Belgium/L=Brussels/O=Approach Belgium/OU=Apache test
certificate/CN=127.0.0.1:xxj31ZMTZzkVA
Does 2.2.6 it use another hash algorithm by default or so ?
1. What is your platform?
2. Have you tried with the md5 password ($apr1$nvFsZ/..$kPIYJ444oUVBALuYT2nZJ0)
or the SHA password ({SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=)?
Regards
Rüdiger
Re: FakeBasicAuth changes
Additional info: I also tried without FakeBasicAuth, to have the
interactive password box, and with another user 'frank' and the password
'sinatra'.
Depending on my password file, I get the following errors:
- frank:mlVo7KaArYZhg
-> dialog box -> frank/sinatra
-> user frank: authentication failure: Password Mismatch
- frank:$apr1$9U1.$C.5OJhZ4UxxM9SIzv4XAY0
-> no dialog box
-> configuration error: couldn't check access. No groups file?
- frank:{SHA}7DUut/wAuxmp4mKiKKNr9eEUeG0=
-> no dialog box
-> configuration error: couldn't check access. No groups file?
So, MD5 & SHA-1 are not supported.
With FakeBasicAuth, I get exactly the same password error:
user /C=BE/ST=Belgium/...: authentication failure: Password Mismatch
It seems that the CRYPT algorithm that is used is not compatible with
the previous versions !?!
When I try 'htpasswd.exe -nbd', it responds 'Automatically using MD5
format'.
I use OpenSSL 0.9.8e.
Nick Gearls wrote:
I tried both MD5 and SHA-1 passwords.
I'm on Windows XP/2003.
I always get 'user /...: authentication failure for "/path/":
Password Mismatch', although my password file looks correct:
/C=BE/ST=Belgium/L=Brussels/O=Approach Belgium/OU=Apache test
certificate/CN=127.0.0.1:xxj31ZMTZzkVA
Does 2.2.6 it use another hash algorithm by default or so ?
1. What is your platform?
2. Have you tried with the md5 password
($apr1$nvFsZ/..$kPIYJ444oUVBALuYT2nZJ0)
or the SHA password ({SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=)?
Re: FakeBasicAuth changes
And I have the same on Linux (2.2.6) :-(
Nick Gearls wrote:
Additional info: I also tried without FakeBasicAuth, to have the
interactive password box, and with another user 'frank' and the password
'sinatra'.
Depending on my password file, I get the following errors:
- frank:mlVo7KaArYZhg
-> dialog box -> frank/sinatra
-> user frank: authentication failure: Password Mismatch
- frank:$apr1$9U1.$C.5OJhZ4UxxM9SIzv4XAY0
-> no dialog box
-> configuration error: couldn't check access. No groups file?
- frank:{SHA}7DUut/wAuxmp4mKiKKNr9eEUeG0=
-> no dialog box
-> configuration error: couldn't check access. No groups file?
So, MD5 & SHA-1 are not supported.
With FakeBasicAuth, I get exactly the same password error:
user /C=BE/ST=Belgium/...: authentication failure: Password Mismatch
It seems that the CRYPT algorithm that is used is not compatible with
the previous versions !?!
When I try 'htpasswd.exe -nbd', it responds 'Automatically using MD5
format'.
I use OpenSSL 0.9.8e.
Nick Gearls wrote:
I tried both MD5 and SHA-1 passwords.
I'm on Windows XP/2003.
I always get 'user /...: authentication failure for "/path/":
Password Mismatch', although my password file looks correct:
/C=BE/ST=Belgium/L=Brussels/O=Approach Belgium/OU=Apache test
certificate/CN=127.0.0.1:xxj31ZMTZzkVA
Does 2.2.6 it use another hash algorithm by default or so ?
1. What is your platform?
2. Have you tried with the md5 password
($apr1$nvFsZ/..$kPIYJ444oUVBALuYT2nZJ0)
or the SHA password ({SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=)?
dev@httpd.apache.org
Hi, I think mod_proxy should be enhanced/fixed in some way: - If I use ProxyPass & ProxyPassReverse to forward connection from "proxy" to "back-end", ProxyPassReverse adapts the "Location" header from "back-end/..." to "proxy/...". 1. Why only the "Location header" ? 2. In case you access your proxy in HTTPS, and your back-end in HTTP, ProxyPassReverse should also remove the protocol from all headers 3. ProxyPass should do the same for all headers - fixing the protocol, and possibly the host if "ProxyPreserveHost" was not used To summarise, this should be done for _all_ headers: - ProxyPass: change "https://proxy/..."; to "http://back-end/..."; or "http://proxy/..."; if "ProxyPreserveHost" was used (replace "https" by "protocol1" and http by "protocol2" to be generic) - ProxyPassReverse: change "http://back-end/..."; to "https://proxy/..."; Does it sound sensible ? Obviously, you could do it manually with "Header" & "RequestHeader" (although I have problems to do it with 2.24 - is there a known issue with mod_proxy), but you have to know every header by advance, and I do not see any reason to not do it systematically. Please correct or acknowledge my thought. Nick
dev@httpd.apache.org
Maybe I didn't describe the global picture, sorry. There are obviously known headers that will never contain a URL, like the "Date" you mentioned, and several others. However, you may have other headers containing the host URL, like "Destination" for the WebDAV protocol. So, I was asking to check every header (we may potentially discard known ones, but that's an optimization) for the proxy/back-end URL, and fix it if needed. Concretely, when using WebDAV, you can copy a file from one location to another; the client sends a "COPY" command on a URI "/dir/file", and sets a "Destination" header to - in my example - "https://proxy/newdir/newfile";. The WebDAV server refuses this because it receives a command to copy from "http://back-end/dir/file"; to "https://proxy/newdir/newfile";. I personally have the problem with WebDAV, which is obviously a common one because of the standard, so we could fix only that header; but I imagine some other applications could use the same mechanism, so why not generalizing this to all headers ? Excepting the little overhead, I find this a very robust solution. I don't think it breaks anything, so I would not see it as a behavior redesign. Nick Kew wrote: On Wed, 03 Oct 2007 12:11:09 +0200 Nick Gearls <[EMAIL PROTECTED]> wrote: Hi, I think mod_proxy should be enhanced/fixed in some way: - If I use ProxyPass & ProxyPassReverse to forward connection from "proxy" to "back-end", ProxyPassReverse adapts the "Location" header from "back-end/..." to "proxy/...". 1. Why only the "Location header" ? Because that's the only header you had that contained the string "back-end" with URL semantics. 2. In case you access your proxy in HTTPS, and your back-end in HTTP, ProxyPassReverse should also remove the protocol from all headers 3. ProxyPass should do the same for all headers - fixing the protocol, and possibly the host if "ProxyPreserveHost" was not used How would you propose to rewrite, for example, the "Date" header? Does it sound sensible ? I expect if you think through what you're asking, you'll eventually redesign the existing behaviour. If not, tell us what's wrong.
dev@httpd.apache.org
I agree, we have to check if it latches the back-end before changing it to the front-end, and vice-versa. This way, it sounds totally safe, no ? Graham Leggett wrote: On Wed, October 3, 2007 1:03 pm, Nick Kew wrote: It would break headers that contain a URL-like pattern that isn't a URL. And if you think that's unlikely, just look at the number of false positives in desktop software (e.g. mailers) that guesses links and makes http://www.example.org or even just www.example.com clickable. As I recall the ProxyPassReverse does an exact string prefix match on Location, and if there is a match, the header is changed, otherwise it leaves the header alone. By saying "ProxyPassReverse" it seems sane to be telling the proxy that it should hide every and all occurences of the backend url by replacing it with the frontend url, although from the perspective of changing existing behaviour in existing installations, a compromise would be to identify headers used by WebDAV, and alter those headers as well as Location. Regards, Graham --
Apache 2.2.4 and VS 2008
Hello, I'm trying to build Apache 2.2.4 with VS 2008 Beta 2 (under Vista to make it simple), and I have a problem. I patched several stuff to have it compile nicely, but the program crashes at startup: "An unhandled non-continuable exception was thrown during process load. The program '[4636] httpd.exe: Native' has exited with code -1073741701 (0xc07b)." Everything is compiled in native code (I migrated the defaults projects to VC2008 ones), and I added MSVCR90*.dll to my apache/bin directory. Any idea ? For info, here are the changes I did in the sources: APR - apr.h --- 81: #define _WIN32_WINNT 0x0600 220: #define APR_HAVE_IPV6 1 APR - network/multicast.c - 136: #if defined(MCAST_JOIN_SOURCE_GROUP) || (_WIN32_WINNT >= 0x0600) 148: #if defined(MCAST_JOIN_SOURCE_GROUP) || (_WIN32_WINNT >= 0x0600) APR - misc/win32/rand.c (others?) --- #include #include after #include "..." libxml - config.h - 90: # if _MSC_VER < 1500 # define vsnprintf(b,c,f,a) _vsnprintf(b,c,f,a) # endif libxml - wsockcompat.h -- 24: //#define HAVE_GETADDRINFO -- Thanks, Regards, Nick
High security
Hello, As some may now, ModSecurity adds a very easy and effective way to put Apache in jail, but chrooting the process after its initialisation, thus putting all listening processes in jail. You specify one directive, and the only thing you have to put in the jail is your htdocs and logs directories; all other files (conf, modules, httpd, libraries, etc.) are outside of the jail. This is really top security - it's almost impossible to find something to hack. Unfortunately, the only thing that does not work is a graceful restart, as the process has no more access to all normal files. Couldn't it be possible to separate the main process in 2 - one real master performing the start/stop/restart, and one "almost main" chrooted process which would spawn the listening children processes ? The chrooted process could be implemented in the core, or it could be left to ModSecurity. That would be the top security, much more secure than any solution based on IIS for instance. Do you think this could be envisioned ? Thanks, Nick
Re: High security
Yes, chroot could potentially be escaped.
Although, if you chroot the main process, then you spawn child processes
under another userid, like in standard Apache config under Unix, I
expect it to be really very difficult to escape if
1. you are not root
2. if the only files available are log files and htdocs files (even no
HTML files in case of a reverse proxy
Obviously, we could imagine a vulnerability (like a buffer overrun) in
the child Apache process that would send a signal to the main process to
use a second vulnerability, but I really find that chrooting Apache
provides a very good defense.
Now, my main question is "do I add all executables, load modules,
libraries, etc. ?". I need to if I want graceful restart (and you
usually need that in a real production environment). This definitely
higher the risk, so why not trying to improve this ?
Defense in depth is a golden rule in security, no ? So, even if chroot
may not be totally bullet proof, it should, imho, be used. And, if we
want Apache to be as secure as possible, it should be as
"chroot-friendly" as possible.
I hope this could convince some key developers ...
Nick
Plüm wrote:
-Original Message-
From: Colm MacCarthaigh [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 24. Januar 2008 13:16
To: dev@httpd.apache.org
Subject: Re: High security
On Thu, Jan 24, 2008 at 01:10:23PM +0100, Nick Gearls wrote:
You specify one directive, and the only thing you have to
put in the
jail is your htdocs and logs directories; all other files (conf,
modules, httpd, libraries, etc.) are outside of the jail.
This is really
top security - it's almost impossible to find something to hack.
Well don't kid yourself, it makes privilege escalation by
certain routes
much harder, but it's not even clost to almost impossible. There are
many forms of IPC available between the children and the root-level
Apache process anyway, and if you manage to exploit that it's
game over
anyway (including breaking out of the jail).
Yep. chroot was never designed to be a security feature. It can make
things more difficult to leave a jailed area.
See also http://kerneltrap.org/Linux/Abusing_chroot
or have a look at
#include
#include
#include
#include
int main(int argc, char *argv[])
{
FILE *file;
chroot("/tmp/zw/blah1");
chdir("/");
file = fopen("blah1", "w");
fprintf(file, "Hello\n");
fclose(file);
mkdir("foo", 493);
chroot("foo");
chdir("..");
chdir("blah2");
file = fopen("blah2", "w");
fprintf(file, "Hello\n");
fclose(file);
return 0;
}
which allows you to escape the chroot of /tmp/zw/blah1 if
you are still root at the point of time mkdir is executed
and write a file to /tmp/zw/blah2
Regards
Rüdiger
Certificate validation problems trapping - bug #35083
Hello, The proposed patch generalizes a mechanism that currently exist, but is incomplete. It now allows to accept all SSL connections that fail for any reason related to certificate verification or validation. Could this be included in next release ? This has a huge impact on the user, as it is possible to give a meaningful error message in case of a problem (like "your certificate is revoked"), instead of a network error at SSL level. The patch is quite simple, and it is used in several major Governmental servers in Belgium, so we shouldn't expect problems. Regards, Nick
Re: High security
I'm running the patch for one week on a production server, and it works perfectly (http://svn.apache.org/viewvc?view=rev&revision=611483). When using Apache as a reverse proxy, the chroot environment is totally empty (except libgcc_s.so.1). Could we include this in next build ? As it is very limited (basically 3 basic function calls plus the logging), it is trivial to review. +1 Regards, Nick [... discussion about chroot effectiveness and letting the final choice to the user to use it or not ...]
