H2S114: Apache.HTTP-serv,lit.rev:

Apache is a pre-built and hard-coded 1) perpetual listener, 2) HTTP/S response function and 3) a filesystem directory Imagine a troop quarters: as long as everyone can be awoken, you only need one guy who is not asleep. That guy, in WAMP, is Apache.

H3S1: PHP x Apache-HTTP:

Hu: Pre: Most of the protocol selection is enabled by Apache, only, so we have one safe-fail point at that level, and are as fragile as the semiconductor supply chain, and even that, is largely hard-coded. Apache, unlike PHP, is not a prog-lang, it’s a forced.use-library. If the protocol-switch here, fundamentally best #, occurs at the level of browser->Apache, pre-PHP, then our other protocol switches, which are proposed by browsers-JS to cut directly from the browser into the server, are on a different level; it would be incorrect to have protocol switches occur on 2 different l.o-as.

H3S2: Apache Virtual Host for IP access to director(ies) lit-rev:

<Apache, vhosts>: The term Virtual Host refers to the practice of running more than one web site (such as company1.example.com and company2.example.com) on a single machine. Virtual hosts can be “IP-based“, meaning that you have a different IP address for every web site, or “name-based“, meaning that you have multiple names running on each IP address. The fact that they are running on the same physical server is not apparent to the end user.

H4S1: Apache IP-based Virtual Host:

<ip-based.html, a-r><fbno>: As the term IP-based indicates, the server must have a different IP address/port combination for each IP-based virtual host. This can be achieved by the machine having several physical network connections, or by use of virtual interfaces which are supported by most modern operating systems (see system documentation for details, these are frequently called “ip aliases”, and the “ifconfig” command is most commonly used to set them up), and/or using multiple port numbers. == In the terminology of Apache HTTP Server, using a single IP address but multiple TCP ports, is also IP-based virtual hosting.

H4S2: Name-based Virtual Host:

H5S1:<Apache>Name-based vs IP-based: IP-based virtual hosts use the IP address of the connection to determine the correct virtual host to serve. Therefore you need to have a separate IP address for each host. == With name-based virtual hosting, the server relies on the client to report the hostname as part of the HTTP headers. Using this technique, many different hosts can share the same IP address. == Name-based virtual hosting is usually simpler, since you need only configure your DNS server to map each hostname to the correct IP address and then configure the Apache HTTP Server to recognize the different hostnames. Name-based virtual hosting also eases the demand for scarce IP addresses. Therefore you should use name-based virtual hosting unless you are using equipment that explicitly demands IP-based hosting. Historical reasons for IP-based virtual hosting based on client support are no longer applicable to a general-purpose web server. == Name-based virtual hosting builds off of the IP-based virtual host selection algorithm, meaning that searches for the proper server name occur only between virtual hosts that have the best IP-based address.

Paying for domain names is like paying to name files on your computer. Domain registrars are man in the middle interceptions into a financial viral block. The extorted payment subsequently allows your traffic to go through to the desired destination via their subpar STUN server.<Les-Mis, a-r>

H3S3: Apache as an extension of Windows.Security-Firewall<Turing>:

// see-refs, apache.org // check WAMP.public-IP playlist, and maybe cite here after unlist

<Apache, a-r>: Access | control refers to any means of controlling access to any resource. This is separate from authentication and authorization. [D]: Left click->Apache in WAMP-taskbar, the recommended main doc and conf-files.

H4S1: Access Control, Apache:

Hu: After a first.2-viewings of<TheApacheFoundation, a-r>talk on Access Control, I concluded that H5S1: access control is the key vocab from Apache’s | nomenclature for security | features<WP.MIC-H2S4, AAM-plugin>From this video, I got that the 4 key words for access control in Apache are H6S1: Order H6S2: Deny H6S3: Allow H6S4: Satisfy H5S2: These 4 are rooted in the binary | access | paradigm: whitelist or blacklist. In a whitelist paradigm, all users are access | denied by default; based on my initial testing in<WP.MIC-H2S74>, concluding at<H3S7-H4S1>, there, this is consistent with the behavior of Verizon and Microsoft Security as well; in contrast, the blacklist paradigm follows that # all users are permitted | by default, and a blacklist defines which users are blocked. Certain hybrid formations can be found as well, but not recommended before 1,000,000 users per expected visit, and that pushes the boundary of private | web<WP.MIC-H2S70>

H4S2: Require keyword:

Hu: Again, this came up as important in the video on Access Control by TheApacheFoundation<a-r>; it seems like quite a bit of the access | control stack, especially for defining user.based-lists, is based on this keyword, in design. Notes: Require keyword is for user based authentication. Require all/any/none.<10 min or so so far.

H5S1:<Apache>: The Require provides a variety of different ways to allow or deny | access to resources. In conjunction with the RequireAll, RequireAny, and RequireNone directives, these requirements may be combined in arbitrarily | complex ways, to enforce whatever your access policy happens to be. H6S1: Hu: Access | policy is a political | statement<WP.MIC-H2S120>as well as a moderation | policy and should be determined prior-to | programming. H6S1: RequireAll:<Apache>: <RequireAll> and </RequireAll> are used to enclose a group of authorization directives of which none must fail and at least one must succeed in order for the <RequireAll> directive to succeed. If none of the directives contained within the <RequireAll> directive fails, and at least one succeeds, then the <RequireAll> directive succeeds. If none succeed and none fail, then it returns a neutral result. In all other cases, it fails. H6S2: RequireAny:<Apache>: <RequireAny> and </RequireAny> are used to enclose a group of authorization directives of which one must succeed in order for the <RequireAny> directive to succeed. If one or more of the directives contained within the <RequireAny> directive succeed, then the <RequireAny> directive succeeds. If none succeed and none fail, then it returns a neutral result. In all other cases, it fails. H6S3: RequireNone: <RequireNone> and </RequireNone> are used to enclose a group of authorization directives of which none must succeed in order for the <RequireNone> directive to not fail. If one or more of the directives contained within the <RequireNone> directive succeed, then the <RequireNone> directive fails. In all other cases, it returns a neutral result. Thus as with the other negated authorization directive Require not, it can never independently authorize a request because it can never return a successful result. It can be used, however, to restrict the set of users who are authorized to access a resource.

H5S2: Examples of Require in C:\wamp64\bin\apache\apache2.4.51\conf\httpd.conf:

<Directory "${INSTALL_DIR}/www/">
Options +Indexes +FollowSymLinks +Multiviews
AllowOverride all
# Don't modify this line - Instead modify Require of VirtualHost in httpd-vhost.conf
Require local
</Directory>

<Files ".ht*">
    Require all denied
</Files>

<Directory "${SRVROOT}/cgi-bin">
    AllowOverride None
    Options None
    Require all granted
</Directory>

<Directory />
    AllowOverride none
    Require all denied
</Directory>

H5S3: Require ip [ip-address]:

H6S1: // testing:

H4S3: Word salad, general:

Syntax error, configuration files. From all. From an address, IP, hostname, environment variable.

H4S4: mod_authz_core:

Hu: Files with the mod_ prefix can be found in C:\wamp64\bin\apache\apache2.4.51\modules and are labeled as SO Files: H5S1: SO Files: // write

H4S5: mod_authz_host:

<Apache>: If you wish to restrict | access to portions of your site based on the host address of your visitors, this is most easily done using mod_authz_host.

H4S6: mod_rewrite:

H4S7: <Location> tag:

<MIT.edu 10.5.60>: The <Location> and </Location> tags create a container in which access control based on URL can be specified. For instance, to allow people connecting from within the server’s domain to see status reports, use the following directives:


<Location /server-status>
    SetHandler server-status 
    Order deny,allow
    Deny from all 
    Allow from <.example.com>
</Location>

Hu: Apache’s programming | language is a baby-cross<amateurs!> between HTML, with the tags setup, and some semblance of XML, and PHP, with the use of the word Require. The configurational | aspect is reminiscent of HTML-attributes, or CSS<Turing>PHP and MySQL, generally, are action-oriented,langs<Turing-2>

H4S8: Basic-implementation:

H5S1: Success! By establishing ‘Require all granted’ in C:\wamp64\bin\apache\apache2.4.51\conf\extra\httpd-vhosts.conf :<Athi-Tech, a-r><WP.MIC-H2S5,H3S7>:

Change "Require local" in the localhost to "Require all granted", or by "Require ip [ip-address]"<Apache, a-r>
	Change, also, the desired directory to this same permission within the <Directory> tag. 
	Important: WAMP must be restarted for the Require change to take E.

I was able to, in coordination with the 2x firewall changes established in<WP.MIC-H2S74>, open up my public IP, such that even on my phone, when it’s off-router, can access 1) localhost-home, and 2) a service, p-dash, for testing. Still, some URL-finagling, on the level of PHP-script, is necessary to make this functional<WP.MIC-H2S41>

H3S4: Apache is a programming interface; configurations:

H4S1: Basic-syntax:

Hu: Apache is a programming | interface, in which half the programming # occurs inside config | files; these files are read by Apache’s | parser, which is 1/2 of the other programming, which means that Apache is 1/2 lower level than PHP<WP.MIC-H2S35>, allowing it to be PHP’s connection protocol-tier<2nd.order-compiling><Turings-dirty><fbno>

H5S1: Variable declarations and calls:

Define INSTALL_DIR c:/wamp64
Define APACHE_DIR ${INSTALL_DIR}/bin/apache/apache${VERSION_APACHE}
Define SRVROOT ${INSTALL_DIR}/bin/apache/apache${VERSION_APACHE}

ServerRoot "${SRVROOT}"

Hu: From C:\wamp64\bin\apache\apache2.4.51\conf\httpd.conf Apache is a marvel of variable | management<WP.MIC-H2S45>; most likely, its actual code is quite simple, found in .exe files that are non–transparent<mal-practice>, but these configs, which are just variable declaration requires<invented><Turing>.

Variable declarations are initiated by the Define keyword, and do not require a = operator<weird>. Variable calls are by the ${name_of_variable} syntax; we can CTRL+F for the name in a call, to find its value, in the definition.

⭐️ Any statement that you make that is logical, will happen. If nothing happens, then your statement was not logical. Making things happen is not my God power; my God power is that every statement I make is logical. This power is propagated to t.s-fs. Therefore, if you have nothing logical to say, pass the buck, and avoid polluting the airwaves with illogical bytes #mental-health.<mat.push-2, 10/22>

H5S2: # comments out lines, and this is used frequently, in the default-configs.

Post: Several config files are disabled by default in httpd.conf, which is the central | file, very possibly<100%>the only one the parser reads, for redirects, via include, a rather elementary | implementation<H2S116>

H3S5: Apache’s.core-listening,func:

From C:\wamp64\bin\apache\apache2.4.51\conf\httpd.conf:

Listen 0.0.0.0:80
Listen [::0]:80

Hu: This file is mostly commented | lines and # of true | configs is maybe 7% of the 575 total, or 40.<Apache>: Listen: Allows you to bind Apache to specific | IP addresses and/or ports, instead of the default. Hu: Apache listens on port 80, by default, the HTTP-port.