Re: [users@httpd] redirect vs. rewrite

On 26/06/2017 17:58, Daniel wrote: Nigel, either I misunderstood you but Redirect redirects everything after the matched part and appends the rest to the target Yes, agreed, it was by mistake, Daniel. See subsequent emails from Eric. Nigel

Re: [users@httpd] redirect vs. rewrite

On 26/06/2017 17:00, Eric Covener wrote: On Mon, Jun 26, 2017 at 5:58 PM, Nigel Peck <np.li...@sharphosting.uk> wrote: They wouldn't redirect in the same way, but it would be the same type of redirect. Since the second one preserves the page on the site that it is redirecting, which is

Re: [users@httpd] redirect vs. rewrite

On 26/06/2017 16:56, Felipe Pereira wrote: Yes. In the second line you could use R=permanent or R=301 so they would redirect the same way. They wouldn't redirect in the same way, but it would be the same type of redirect. Since the second one preserves the page on the site that it is

Re: [users@httpd] redirect vs. rewrite

Sorry, one other point, using `[R]` in number two will generate a 302 redirect whereas the first, using the permanent keyword, will generate a 301. On 26/06/2017 15:07, Nigel Peck wrote: Also note that the first one will always redirect to the root of the target domain, but the second one

Re: [users@httpd] redirect vs. rewrite

Also note that the first one will always redirect to the root of the target domain, but the second one will redirect to the same page on the target domain. First one: (taking Daniel's comment in to account) /example redirects to http://www.domain.com/ Second one: /example redirects to

Re: [users@httpd] AllowOverride - Mis-behaving Default

> On 18 Jun 2017, at 23:41, Frank wrote: > > Nigel, > > The point is that the default value changed for 2.3 (and hence 2.4), and you > seem to be missing it, yes. > > As for why that change was made, the development mailing list might be better > suited for that thread.

Re: [users@httpd] AllowOverride - Mis-behaving Default

On 18/06/2017 18:01, Frank wrote: > As per http://httpd.apache.org/docs/current/mod/core.html#allowoverride : > > Default:AllowOverride None (2.3.9 and later), AllowOverride All (2.3.8 and earlier) I'm not sure what your point is. I am aware of that and it supports the point I am making

Re: [users@httpd] AllowOverride - Mis-behaving Default

On 18/06/2017 16:38, Frank wrote: You probably have another block that has AllowOverride set, for the / path or another. Inspect all files shipped by CentOS, and the ones you modified. I only have one config file, since I merged all of the others in to it that I needed. I already double

[users@httpd] AllowOverride - Mis-behaving Default

Hi, According to the documentation[1], the default for `AllowOverride` is `None`, and when `AllowOverride` is set to `None`, .htaccess files are not read at all. When I set `AllowOverride` to `None` explicitly, I find that is the behaviour I see, but when I don't specify it at all, the

Re: [users@httpd] mod_rewrite - Setting Environment Variables

On 04/02/2017 07:40, Eric Covener wrote: Internal redirects, which happen for almost any substitution in htaccess rewritees, cause existing environment variables to be renamed to REDIRECT_$varname. Thanks Eric. - To

[users@httpd] mod_rewrite - Setting Environment Variables

Hi, I am having trouble with how mod_rewrite handles environment variables that are set with the [E=VAR:VAL] flag for RewriteRule. I am setting an environment variable to prevent a loop. The logs show it is set, and then matched, but then on the subsequent iteration of the rules it is no