[lug] Apache Virtual Hosting Question

duboulder blug-mail at duboulder.com
Thu Apr 4 13:25:39 MDT 2019


Hmm.

This works for the sites I manage:
    <head><link type="text/css" rel="stylesheet" href="/css/font.css"/></head>
Where <site-assets-dir>/css/font.css contains a url ref:
    @font-face {
        font-family: "Liberation Serif";
        src: url("/font/LiberationSerif-Regular.ttf") format("truetype");
        font-style: normal;
        font-weight: normal;
    }
This has an added wrinkle compared to your situation in that this is using
SNI and TLS for the separate www and beta sites on the same host/port.
So the protocol and host are preserved when clients fetch the fonts [if the asset
file names don't match in site-assets-dir/font and font.css I see the ua fetch fail,
so it is doing per-site fetches for us].

With javasript, ua caching can cause issues. A page refresh/reload isn't enough sometimes.
Maybe that is complicating things for you with css.

Hope you find out what is going on.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, April 3, 2019 11:32 PM, D. Stimits <stimits at comcast.net> wrote:

>> On April 3, 2019 at 11:06 PM duboulder <blug-mail at duboulder.com> wrote:
>>
>> I haven't used apache in quite a while, but maybe my questions will help you
>> figure it out.
>>
>> 1) Do you really mean you are trying to use //url-space/path instead of /url-space/path?
>>     E.g. if site1.local's root maps to /var/www/site1, then a site relative css link reference
>>     would be <link type="text/css" rel="stylesheet" href="/css/main.css"/> where
>>     /var/www/site1/css/main.css is the external stylesheet.
>
> In order to preserve http or https protocols, dependent upon whatever the end user uses, I changed URLs from explicitly naming http or https. If I put a URL as a link inside of a document starting with http or https, then that protocol is forced. If instead I use "//" instead, then the protocol which was requested is honored regardless of it being http or https. Example: "//localhost/images" would resolve to "http://localhost/images" if "http" was used, or to "https://localhost/images" if https had been used originally. This is just one of the steps I'm trying to learn for better validation. This part works as expected.
>
>> 2) Do the apache access logs or the ua debug consoles show the css request going
>>     to the host-name you expect? The web-console in ff has a network tab that will show
>>     you what resource urls are being fetched. I expect chrome has something similar.
>>
>>     wget --save-headers --header='Host: site1.local' [http://ip.add.re.ss:port/](http://ip.add.re.ss/) -O site1.html
>>     wget --save-headers --header='Host: site2.local' [http://ip.add.re.ss:port/](http://ip.add.re.ss/) -O site2.html
>>     If these files don't differ your vhost configuration isn't doing what you want.
>
> Comment in section below...
>
>> 3) An apache vhost needs more than just a name/address/port. It also needs to specify
>>     the root directory that maps to the url http://site1.local/. Might also need access
>>     control settings. Your sites can use the same address/port, just need different host
>>     names. The vhost functionality is probably enabled by default, but you may want check
>>     that. IIRC the status page (if enabled) will also show builtin modules.
>
> I have both a "/var/www/html/" directory which responds to "localhost" or "127.0.0.1". I also have a "/var/www/html_alt/" directory if I bring up a browser with "local_alt". If I put a URL to a background image in the default area, then this always works as expected. If I put a relative URL in say index.html of the html_alt, then this too works (the virtual setup correctly knows to use something like the "html/images/" directory or "html_alt/images/" directory when called from index.html).
>
> However, a URL within an external CSS stylesheet fails to honor this. If I have "/var/www/html_alt/css/style.css", and this external stylesheet refers to either "images/background.png" or to "/images/background.png" or to "//images/background.png", then it wants the subdirectory in the wrong virtual domain. I can't seem to get external CSS files of alternate domains to go to the correct directory tree. I'm wondering if I'm barking up the wrong tree and should just use multiple servers, but this seems a bit heavy-handed.
>
> What is needed to get a URL in an external stylesheet to be honored by apache virtual hosts? I was hoping that I could avoid writing specific domains into the CSS so the CSS would be interchangeable no matter which domain I copy it too.
>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Wednesday, April 3, 2019 6:19 PM, D. Stimits <stimits at comcast.net> wrote:
>>
>>> I ran into a case where I wanted to test a couple of independent web "creations" on my Fedora system. So I set up virtual names, and my "/etc/hosts" has a couple of different domains. The content is in different subdirectories of "/var/www/". Within the actual html/css I'm trying to learn to a bit more modern, and so for example I've referred to some URLs via the "//use/the/requesting/protocol/instead/of/hard/coding/" syntax. Only this doesn't work for external CSS.
>>>
>>> If I don't actually code the explicit name into the URL it doesn't work. I didn't want to do mod_rewrite, but I did want to html/css to be portable without embedding a host name into it. Should I be running more than one server instance on different ports instead of working with virtual servers?
>>>
>>> I would hope that if I refer to a site as "http://custom", and "custom" is in "/etc/hosts", that any relative URLs in the html would also assume that "custom", but it doesn't seem to be the case.
>>>
>>> Thanks!
>>
>> _______________________________________________
>> Web Page: http://lug.boulder.co.us
>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20190404/606d5bb5/attachment.html>


More information about the LUG mailing list