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.defaultViewdocument.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(valueca.length)value=value[a[c++]];return(value?value:);}
Richfaces.evalMacro=function(template,object)
{var _value_=;if(Richfaces.VARIABLE_NAME_PATTERN.test(template))
{if(template.indexOf('.')==-1){_value_=object[template];if(!_value_)_value_=window[template];}
else{_value_=Richfaces.getObjectValue(template,object);if(!_value_)_value_=Richfaces.getObjectValue(template,window);}
if(_value_typeof
_value_=='function')_value_=_value_(object);if(!_value_)_value_=;}
else{try{if(Richfaces.browser.isObjectEval){_value_=object.eval(template);}
else with(object){_value_=eval(template);}
if(typeof _value_=='function'){_value_=_value_(object);}}catch(e){LOG.warn(Exception:
+e.Message+\n[+template+]);}}
return _value_;}
Richfaces.evalSimpleMacro=function(template,object)
{var
value=object[template];if(!value){value=window[template];if(!value)value=;}
return value;}
Richfaces.getComponent=function(componentType,element)
{var attribute=richfacesComponent;var
type=richfaces:+componentType;while(element.parentNode){if(element[attribute]element[attribute]==type)
return element.component;else
element=element.parentNode;}}
Richfaces.browser={isIE:(!window.opera/MSIE/.test(navigator.userAgent)),isIE6:(!window.opera/MSIE\s*[6][\d,\.]+;/.test(navigator.userAgent)),isSafari:/Safari/.test(navigator.userAgent),isOpera:!!window.opera,isObjectEval:(Richfaces.eval!=undefined),isFF2:(!window.opera/Firefox\s*[\/]2[\.]/.test(navigator.userAgent)),isFF3:(!window.opera/Firefox\s*[\/]3[\.]/.test(navigator.userAgent))};Richfaces.eval=function(template,object){var
value='';try{with(object){value=eval(template);}}catch(e){LOG.warn('Exception:
'+e.message+'\n['+template+']');}
return value;};Richfaces.interpolate=function(placeholders,context){for(var k in context){var
v=context[k];var regexp=new
RegExp(\\{+k+\\},g);placeholders=placeholders.replace(regexp,v);}
return
placeholders;};if(!Richfaces.position)Richfaces.Position={};Richfaces.Position.setElementPosition=function(element,baseElement,jointPoint,direction,offset)
{var elementDim=Richfaces.Position.getOffsetDimensions(element);var
baseElementDim=Richfaces.Position.getOffsetDimensions(baseElement);var
windowRect=Richfaces.Position.getWindowViewport();var
I added 2.0.64 and 2.2.17 to Bugzille httpd version list
Subject says it all.
Re: svn commit: r1025666 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy.xml modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c
On 21 Oct 2010, at 7:26 AM, Ruediger Pluem wrote: mod_proxy.h is public. Doesn't this require a bump? It will, yes, but given the gratuitous number of bumps there were for mod_cache, I'm keen to try and group them for mod_proxy if I can. I am wondering how much of mod_proxy.h needs to be public. Regards, Graham --
Re: mod_proxy: optimising ProxyPass per directory
LocationMatch ^/foo(.*) ProxyPass http://somewhere/$1 /LocationMatch Many many many many people have been asking how to implement something like: LocationMatch ^/projects/([^/]+) Require group well..that...stuff. /LocationMatch Could your idea be extended to be usable elsewhere as well? Regards, Graham -- i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/
Re: mod_proxy: optimising ProxyPass per directory
On 21 Oct 2010, at 3:11 PM, Igor Galić wrote: LocationMatch ^/foo(.*) ProxyPass http://somewhere/$1 /LocationMatch Many many many many people have been asking how to implement something like: LocationMatch ^/projects/([^/]+) Require group well..that...stuff. /LocationMatch Could your idea be extended to be usable elsewhere as well? If the group stuff is defined per-directory, then it should Just Work(TM). It is definitely worth smoking out these occurrences, as storing per- directory configs in the global per-server scope is very expensive. Regards, Graham --
Re: mod_proxy: optimising ProxyPass per directory
+1. On Oct 20, 2010, at 7:43 PM, Graham Leggett wrote: Hi all, On sites with large numbers of ProxyPass directives, these directives are matched in turn on every request, and this can take a lot of time, especially when we've already done a location walk. A simple optimisation is to allow this existing syntax: Location /foo ProxyPass http://somewhere/foo /Location to simply be a single mod_proxy alias in a per-directory context. If this syntax is used, the need to walk the proxy alias list is eliminated, and a significant amount of time is saved. This also has the side effect that ProxyPass inside LocationMatch starts working properly (it was broken before): LocationMatch ^/foo(.*) ProxyPass http://somewhere/$1 /LocationMatch In theory, the ProxyPass /foo http://somewhere/; and ProxyPassMatch ^/foo(.*) http://somewhere/$1; syntaxes can be deprecated, as Location/LocationMatch is way simpler to handle. Regards, Graham -- httpd-mod_proxy-perlocation.patch
Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
++1. On Oct 19, 2010, at 3:28 PM, Roy T. Fielding wrote: IMO, removing Limit and LimitExcept would require a bump to httpd 3.x, since it would break almost all existing configs and introduce security holes if the installer is not prepared to rewrite them. Deprecating Limit and LimitExcept can be done in 2.4.x, which means keeping their functionality intact and warning at startup that the feature is less good than the new directives. Roy
Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
All this debate makes me wonder how many people here still *run* and *administer* web sites... How about putting yourself in the shoes of the sys admin before willy-nilly recrafting configs.
RE: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
-Original Message- From: Jim Jagielski Sent: Donnerstag, 21. Oktober 2010 17:22 To: dev@httpd.apache.org Subject: Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c) All this debate makes me wonder how many people here still *run* and *administer* web sites... How about putting yourself in the shoes of the sys admin before willy-nilly recrafting configs. +1. I am one of them :-) Regards Rüdiger
Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
Jim Jagielski wrote: ++1. On Oct 19, 2010, at 3:28 PM, Roy T. Fielding wrote: IMO, removing Limit and LimitExcept would require a bump to httpd 3.x, since it would break almost all existing configs and introduce security holes if the installer is not prepared to rewrite them. Deprecating Limit and LimitExcept can be done in 2.4.x, which means keeping their functionality intact and warning at startup that the feature is less good than the new directives. Roy Big +1 cheers -- Lars Eilebrecht l...@eilebrecht.net
Re: Removing Limit and LimitExcept
On 10/21/2010 10:21 AM, Jim Jagielski wrote: All this debate makes me wonder how many people here still *run* and *administer* web sites... How about putting yourself in the shoes of the sys admin before willy-nilly recrafting configs. I have, and was bit by the nonsensical behavior of Limit (attempting to SetHandler only on specific methods), which is why I crusade to eliminate it in its current form, entirely. Limit PUT SetHandler put-handler /Limit Funny thing, everything goes to put-handler. The error logs at loglevel debug have nothing to say about my stupidity as an administrator. Now how is that not totally broken and bogus?
Re: [vote] Release mod_ftp 1.0.0 as GA
On 10/7/2010 9:23 PM, William A. Rowe Jr. wrote: After some discussion on list about the numbering and quality of mod_ftp today, it seems this is an appropriate time to consider GA, candidate tarballs are up at http://httpd.apache.org/dev/dist/mod_ftp/ - so please vote... +/-1 [ ] Release mod_ftp 1.0.0 as GA I count; issac, wrowe as +1, no 0's, no -1's, however this is not enough for a release. This is the 14th day, and in spite of the activity around the releases of httpd 2.0 and 2.2, we still need final resolution today in order to clear out the pending issues at httpd so we might direct all focus on the next httpd releases come this Hackathon on November 1 and 2. Looking for one affirmative vote, closing this vote at days end.
Re: [vote] Release mod_ftp 1.0.0 as GA
On Thu, 21 Oct 2010 13:46:56 -0500 William A. Rowe Jr. wr...@rowe-clan.net wrote: Looking for one affirmative vote, closing this vote at days end. Haven't looked at mod_ftp at all, but I can do if it'll help. But not on days end timescale! -- Nick Kew
Re: svn commit: r1023387 - in /httpd/httpd/trunk/modules/cache: cache_util.c cache_util.h mod_cache.c mod_cache.h mod_disk_cache.c mod_disk_cache.h
On 21/10/2010 12:03 AM, Guenter Knauf wrote:
Hi Graham,
Am 17.10.2010 01:15, schrieb minf...@apache.org:
Author: minfrin
Date: Sat Oct 16 23:15:52 2010
New Revision: 1023387
URL: http://svn.apache.org/viewvc?rev=1023387view=rev
Log:
Complete the optimisation of Cache-Control header parsing. Make the
cache_control_t structure public so as to be available to mod_disk_cache.
Modified:
httpd/httpd/trunk/modules/cache/cache_util.c
httpd/httpd/trunk/modules/cache/cache_util.h
httpd/httpd/trunk/modules/cache/mod_cache.c
httpd/httpd/trunk/modules/cache/mod_cache.h
httpd/httpd/trunk/modules/cache/mod_disk_cache.c
httpd/httpd/trunk/modules/cache/mod_disk_cache.h
Modified: httpd/httpd/trunk/modules/cache/mod_disk_cache.h
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cache/mod_disk_cache.h?rev=1023387r1=1023386r2=1023387view=diff
==
--- httpd/httpd/trunk/modules/cache/mod_disk_cache.h (original)
+++ httpd/httpd/trunk/modules/cache/mod_disk_cache.h Sat Oct 16
23:15:52 2010
@@ -17,6 +17,7 @@
#ifndef MOD_DISK_CACHE_H
#define MOD_DISK_CACHE_H
+#include mod_cache.h
#include apr_file_io.h
/*
@@ -57,6 +58,8 @@ typedef struct {
/* Does this cached request have a body? */
int has_body;
int header_only;
+ /* The parsed cache control header */
+ cache_control_t control;
} disk_cache_info_t;
typedef struct {
this part of r1023387 breaks the NetWare build of htcacheclean.
That happens because mod_cache.h includes httpd.h which includes os.h
which has a redefine for exit(), and this requires a var defined in
mpm_netware.c - so this would require to link htcacheclean with
mpm_netware.c ...
Not sure but I guess this will break the Win32 build too since there we
have a similar exit() redefine.
Cant we put the structs all into a separate header, f.e. cache_structs.h
which does not include httpd.h?
Gün.
Can confirm issue with htcacheclean and NetWare, although resolution is
outside my skill set.
Additionally, my picky compiler finds the following tweak desirable for
its happiness:
--- httpd-trunk\modules\proxy\mod_proxy_http.c.orig 2010-10-21
07:31:33.46875 +1000
+++ httpd-trunk\modules\proxy\mod_proxy_http.c 2010-10-22 09:04:17.12500
+1000
@@ -1412,11 +1412,10 @@
conn_rec *origin = backend-connection;
apr_interval_time_t old_timeout = 0;
proxy_dir_conf *dconf;
+int do_100_continue;
dconf = ap_get_module_config(r-per_dir_config, proxy_module);
-int do_100_continue;
-
do_100_continue = (worker-ping_timeout_set
ap_request_has_body(r)
(PROXYREQ_REVERSE == r-proxyreq)
Norm
Re: [vote] Release mod_ftp 1.0.0 as GA
On 10/21/2010 4:56 PM, Nick Kew wrote: On Thu, 21 Oct 2010 13:46:56 -0500 William A. Rowe Jr. wr...@rowe-clan.net wrote: Looking for one affirmative vote, closing this vote at days end. Haven't looked at mod_ftp at all, but I can do if it'll help. But not on days end timescale! Extending this is fine; extending it indefinitely isn't :) How long would you like me to hold the vote open? Happy to oblige.
Re: Removing Limit and LimitExcept
On Oct 21, 2010, at 11:16 AM, William A. Rowe Jr. wrote: On 10/21/2010 10:21 AM, Jim Jagielski wrote: All this debate makes me wonder how many people here still *run* and *administer* web sites... How about putting yourself in the shoes of the sys admin before willy-nilly recrafting configs. I have, and was bit by the nonsensical behavior of Limit (attempting to SetHandler only on specific methods), which is why I crusade to eliminate it in its current form, entirely. Limit PUT SetHandler put-handler /Limit Funny thing, everything goes to put-handler. The error logs at loglevel debug have nothing to say about my stupidity as an administrator. Now how is that not totally broken and bogus? Umm, so you tried to use the directive for something that it does not do, never has done, and makes no sense to do ... RTFM. http://httpd.apache.org/docs/2.2/mod/core.html#limit http://httpd.apache.org/docs/2.2/mod/core.html#sethandler http://httpd.apache.org/docs/2.2/mod/mod_actions.html#script It sounds like an excellent feature that almost exists. I simply don't care how many mistaken configs there are in the world when we are talking about breaking configs that are currently correct, including the config we have in trunk and have been shipping since Limit was introduced http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/extra/httpd-userdir.conf.in So I am currently -1 on the whole idea. I see no need to deprecate Limit and LimitExcept. I see considerable harm in removing them entirely. I see no harm in introducing new directives that will do similar functionality in a better way, documenting those directives as the preferred alternative, and modifying our configs accordingly. When we get to 3.0, we can remove Limit and LimitExcept entirely. If you want to move trunk to 3.0a right now, that's fine with me. Roy
