Forum Moderators: phranque
But after several speed tests, I found that regular variables were faster to process, so other than preventing them from being changed by accident there was no real advantage to using a constant.
would these be better / faster to processWell, “better” and “faster” may be entirely different questions. Unless the time factor involved is absolutely vast--like, say, three whole seconds for Method A as opposed to three microseconds for Method B--time should be pretty far down the list. Does time correlate directly with CPU load? Or are you choosing between occupying the entire server for one millisecond vs. taking a tenth of its computing capacity for ten milliseconds?
Env vars aren't just global to your script, but potentially global to every script running on the server.
Just how much "time" is expected to be saved?
You probably don't want to be storing passwords in system-wide environment variables. (?) Env vars aren't just global to your script, but potentially global to every script running on the server.
"I don't have mod_env installed" - mod_env is installed by default, so if you don't have it installed then presumably you've explicitly removed it?
It wouldn't let me combine the flags like [E=foo:bar, E=blah:blah], though,
RewriteRule ^ - [E=PUNC:'"`~!@#$%^&*()-_=+[]{}\|;:/?.><1234567890,]
It said unknown flag '', and escaping it with \" didn't change anything.
RewriteRule ^ -
[E = BASE:/home/example,
E = DATA:%{ENV:BASE}/data,
E = IMAGES:https://images.example.com] The problem here is the trailing comma - since the comma is the flag delimiter, you effectively have an "empty flag" at the end.
RewriteRule ^blah/(%{ENV:PATTERN})(?:/|$) blah/?var=$1
It doesn't help that the tester site I was using doesn't throw an error with the comma
I suspect that another module would slow down each pageload by a few microseconds...
The RewriteRule pattern is a regex (PCRE), you can't use variable expansion of the form %{VARIABLE} here, just as you can't use %{REQUEST_URI} either.
RewriteRule ^ - [E=PATTERN:foo|bar]
# blah/foo => blah/?var=foo
# blah/bar => blah/?var=bar
RewriteCond ^/blah/(%{ENV:PATTERN})(?:/|$)
RewriteRule ^blah/(.+)(?:/|$) blah/?var=$1 What do you mean by "the tester site"? If it's not throwing an error, what is it doing? (Setting the variable?!)
Although the .htaccess file itself is processed (and these env vars are therefore set) on every single HTTP request (CSS, JS, images, other scripts, etc. etc. as well as the page itself) - multiple times per "pageload". So these "env vars" are being unnecessarily (and possibly undesirably) set on and made available to "everything". (I had mentioned above, "global to every script running on the server", which isn't really what I meant and not strictly correct - as @phranque correctly point out above.)
[edited by: phranque at 8:39 pm (utc) on Apr 11, 2020]
[edit reason] disable graphic smile faces [/edit]
RewriteCond ^/blah/(%{ENV:PATTERN})(?:/|$)Is something missing?
unless the .htaccess is cached or something, so it wouldn't actually be downloaded each time?Nope. htaccess is read--and its Regular Expressions are compiled--from top to bottom on every single request. That's what makes htaccess so useful for testing, even if most of the work is done in config: you can change things on the fly. In the other thread I mentioned my test site. I open the htaccess--yup, the “live” one, just the way you would never ever do for a real site--make changes, save, see what happens in the browser, repeat ad lib.
But I'm guessing that it still downloads the entire file for each request, even if they're not processed.Not sure what this means. Can you re-word? * The unintended smiley didn't help either ;) which is another reason for using [ code ] markup.
RewriteCond ^/blah/(%{ENV:PATTERN})(?:/|$)
Is something missing?
RewriteCond %{REQUEST_URI} ^/blah/(%{ENV:PATTERN})/?$ Not sure what this means. Can you re-word?
RewriteRule ^(?:(?:includes|images|cgi-bin)/)|(?:404\.php|.js|.css)$ - [L] but it still had to download the full 6kb .htaccess fileSay what now? Nobody “downloads” the .htaccess file, any more than they “download” the config file. The server reads it.
require_once 'variables.php'; at the top of the page. index.php is 15kb. So when the user opens index.php, it's my understanding that the download size is 35kb (20kb for variables.php + 15kb for index.php).
If .htaccess is 6kb, would the browser be opening 35kb, or 41kb (the 35kb for the PHP scripts + 6kb for .htaccess)?
Putting it another way, let's say that the user is on dial-up and has a download speed of 10kb per second. Ignoring compression, etc, would this page theoretically open in 3.5 seconds, 4.1 seconds, or other?
Further, does this change once the data is in the Apache configuration instead of .htaccess?
If .htaccess is 6kb, would the browser be opening 35kb, or 41kb (the 35kb for the PHP scripts + 6kb for .htaccess)?Nobody is opening .htaccess. Except the server.
one or more times per requestHm, interesting point. Someone hereabouts--it may even have been you (phranque, not csdude)--once explained to me that, when receiving a request, each module in succession does its stuff, potentially including following the htaccess trail all the way up the line. So each separate module--mod_dir, mod_rewrite and so on--has to read through htaccess in order to pick out its own directives. This all takes time ... but on the broader scale of things, definitely not a whole lot of time.
Is that at least in the ballpark of being correct?If you’ve now got a firm grip on the fact that the htaccess file never leaves the server, and nobody but the server can ever set eyes on it ... Yup.
For portability reasons, the names of environment variables may contain only letters, numbers, and the underscore character. In addition, the first character may not be a number. Characters which do not match this restriction will be replaced by an underscore when passed to CGI scripts and SSI pages.That kind of detail is important to internalize: the name has to be in the form [A-Za-z_]\w+ ... but when they say “letters” do they really mean “plain-ASCII letters”? Seems like it would have to mean that.
If you omit the value argument, the variable is set to an empty string.This, too, is worth internalizing, because it’s different from SetEnvIf where if you don’t specify a value, it defaults to 1.