BACKGROUND
According to my experience when my ubuntu workstation is configured on domain with active directory, the user name created for me was according to the following pattern.
domain_name\user_name
Using the userdir extensions of apache on linux will require to use user name in the URL in order to access public_html in the home directory.
PROBLEM A:
Chrome converts all the backslash '\' characters in the URL to forward slash '/' and the resultant url becomes as under that is totally different and always results Not Found.
Firefox on the other hand does not convert back slash to forward slash so http request to intended target is served by web server.
Common solution is to encode back slash in %5C.
PROBLEM B:
If we use a similar path (containing \ in path) in CSS @import construct, the import process of css file as HTTP Get Request is failed by reporting 404 error and the URL reported in the 404 error miss the presence of \ altogether. It means \ is removed from the URL before to invoke GET request against it.
This behavior is common in Firefox and Chrome. But they have uncommon solutions
Firefox needs escaped back slash to work in css import process.
@import url("http://localhost/~domain_name\\user_name/path/to/css");
Chrome as usual needs an encoded back slash solution.
@import url("http://localhost/~domain_name%5Cuser_name/path/to/css");
The unified solution to deal with backslash in a URL is to use %5C. RFC 2396 did not allow that character in URLs at all (so any behavior regarding that character was just error-recovery behavior). RFC 3986 does allow it, but is not widely implemented, not least because it's not exactly compatible with existing URL processors.
Chrome, in particular, does the same thing as IE: assumes you meant a forward slash any time you type a backslash, as you discovered, because that's what Windows file paths do.