Re: Why is 1.3 still on the download page?
On 20 March 2011 20:23, William A. Rowe Jr. wr...@rowe-clan.net wrote: I've seen no objections, and count 3 +1's to remove these, so I'm cleaning this up today. Perhaps also someone would be kind enough to remove the weekly 1.3 bugzilla summary? -- noodl
Re: mod_rewrite patch
2009/12/27 Rich Bowen rbo...@rcbowen.com: A FAQ on the various httpd support channels is how do I make the query string go away. The answer is that you put ? on the end of the target URL, which is a bit of a kludge. Attached is a patch that adds a QSD (qsdiscard) flag that does this a little more elegantly. As with my previous email, I wanted some review first before adding Yet Another Rewrite Flag. Yes please! While the null query string hack works, it is an ugly hack to have to foist on people. I've had to suggest it in an apologetic manner too many times. I'm also aware that a patch of this kind was submitted a couple years back and ignored, but I wasn't able to find it in the archives. Here it is: http://markmail.org/message/utxqiujml7firkdy -- noodl
Re: mod_rewrite patch
2009/12/28 André Malo n...@perlig.de: Yes please! While the null query string hack works, it is an ugly hack to have to foist on people. I've had to suggest it in an apologetic manner too many times. Another point came up while thinking about it: Next time you'll have to explain that RewriteRule foo bar?x=y [QSD] conflicts and QSD wins (as I read the patch(es)). Dunno if that has to be done in an apologetic manner, though ;-) That's a good point. I'd prefer to see the query string preserved in that case. So, QSD only has an effect if the rule contains no query string. Another point is that removing the query string isn't just cosmetic but can have an effect on cacheability. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.9 -- noodl
Re: svn commit: r650010 - /httpd/httpd/trunk/docs/manual/rewrite/rewrite_guide_advanced.xml
On 21/04/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - there is need (updated on the remote host)./p + mirror with data which gets updated automatically on the + as needed on the remote host(s)./p Hi Chris, This doesn't scan right. Sorry to be so picky :-) -- noodl
Re: [PATCH] ap_socache.h mod_socache_*
On 06/03/2008, Chris Darroch [EMAIL PROTECTED] wrote: I was a little puzzled by the name socache because I assumed so meant shared object, like mod_so, until I read the code comments. I wondered if it was true that people would only use this kind of interface to store small objects -- I won't, for one. (We can migrate our session cache to this interface and we cram all kinds of data in there.) mod_sob Also, I wondered if the term cache was necessarily accurate, if some providers allow unlimited persistent storage (DBM, DBD, etc.) I'm hoping to be able to store things with expiry=0 to mean persist as long as possible. Cache also overlaps with the mod_cache and friends which implement something rather different. mod_sob_store With those thoughts in mind, some other possible names presented themselves -- perhaps grouped under modules/foo, where foo is the name of choice? I thought of map, dict, store, table, and hash, possibly with a d (data, distributed) or s (shared) prefix, e.g., mod_dtable, mod_dtable_distcache, etc. I kind of like mod_dict myself, or mod_dtable or mod_dmap. mod_sob_story I'll get my coat. -- noodl
Re: mod_substitute docs
On 12/02/2008, Jim Jagielski [EMAIL PROTECTED] wrote: So if you have substituted content that you think will be re-substituted by another rule, then you should flatten. If they are one-shots, or self contained, or in no way could result in overlaps, then flattening isn't required. :) In your example, which of the two Substitute directives needs to have the 'f', or is it both? -- noodl
RewriteRule unexpected behaviours
Hi, RewriteRule does tilde expansion even without mod_userdir being loaded, and it does so without the usual public_html component being added. This is a) not mod_rewrite's business and b) a practically unknown feature. I'd like to see this feature removed. There's also an issue with the substitution part of a rule being taken as an absolute filesystem path if the first part of the rewriten path corresponds to the name of a directory in root. This is useful but again rarely known and potentially dangerous (with the caveat that / should be protected by Deny). I'd like to see a flag added to RewriteRule to make this behaviour explicit rather than implied. Being a lowly docs-mule I'm not able to make these kinds of changes myself; hopefully that doesn't make this message a heckle from the peanut gallery. Should I file a bug for this? It's a feature request rather than a bug so I thought not. -- noodl
Re: mod_substitute docs
On 22/10/2007, Jim Jagielski [EMAIL PROTECTED] wrote: Say you are looking for 'foo' and have a bucket that contains 'jimfoojag'. The fast way to handle this would be to split off 3 buckets from this, one containing 'jim', the other containing 'jag' and the middle one that contains the substitute for 'foo' (say it's 'bar'). The rub is that the pattern matching looks at buckets only, so you wouldn't see a full bucket that contains 'jimbarjag' and so if you had a search for 'mbarj', it would be missed using the fast way. In the slow way (flattening), instead of creating the 3 buckets, you go ahead and smash them all together resulting in the single bucket that now contains 'jimbarjag'. Now the search for 'mbarj' would succeed. That's much clearer now, thanks. I've committed my first shot, so please give it a critical eye. Is there a need to add further explaination of 'f' here? Also, surely there's a less contrived example than s/foo/bar/.. -- noodl
mod_substitute docs
Hullo, I'm attempting to document this module but can't figure out what the f (flatten) flag does (bucket brigade munging makes my eyes cross). Any clues? Here's a start anyway: http://people.apache.org/~noodl/mod_substitute.xml -- noodl
Re: svn commit: r561477 - in /httpd/httpd/trunk/docs/manual/mod: mod_proxy.html.en mod_proxy.xml
On 01/08/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: slive Date: Tue Jul 31 13:13:50 2007 New Revision: 561477 URL: http://svn.apache.org/viewvc?view=revrev=561477 Log: Docuemnt the x- headers added by mod_proxy_http. PR: 41097 Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy.html.en httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml + ddThe original host requested by the client in the codeHost/code + HTTP request ehader./dd s/ehader/header/ Also, for consistency, should the argument to RewriteOptions in your earlier patch regarding vhosts be capitalised like RewriteOptions Inherit rather than RewriteOptions inherit? It's a small matter, but these things get cargo-culted and lead to the current belief that 'require' should always be lowercase :( -- noodl
Re: svn commit: r561477 - in /httpd/httpd/trunk/docs/manual/mod: mod_proxy.html.en mod_proxy.xml
On 01/08/07, Vincent Bray [EMAIL PROTECTED] wrote: s/ehader/header/ D'oh! Wrong. List. Sorry. -- noodl
Re: svn commit: r541138 - in /httpd/httpd/trunk: docs/man/ab.8 docs/manual/programs/ab.html.en docs/manual/programs/ab.xml support/ab.c
On 24/05/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sctemme Date: Wed May 23 19:19:04 2007 New Revision: 541138 Thanks Sander, I subscribed to the httpd-cvs list (as linked to from the httpd site) three days ago but haven't seen any commits. Is that list still active? I got the hi, welcome to the list email so I guess my signup was ok.. -- noodl
Re: [Issue] External links @ the wiki, aka pagechange wars
On 24/05/07, Mads Toftum [EMAIL PROTECTED] wrote: +1 - I don't think a single users abuse should force us into making a catch all policy. Part of the price of running a wiki is that you'll have to deal with abuse from time to time. I also agree with all of Rich's sentiments, but I feel a policy document would help, just to have something to point to when dealing with this guy in particular. Without it or some recognised kind of forum for wiki discussions (I'm not sure [EMAIL PROTECTED] counts as that) we're just back to this kind of commitwar. -- noodl
