I want my site to show up as www.mysite.com, not www.mysite.com/
Does Apache add a trailing slash after a domain name by default, or does the browser append it? If I want to prevent this using an .htaccess, what would the url rewrite rule be?
If you request:
http://myhost.com
The request needs to look like this in HTTP:
GET / HTTP/1.0
Host: myhost.com
For historical reasons, some browsers did append the slash because otherwise it translates to
GET <nothing> HTTP/1.0
Host: myhost.com
Which would be an illegal request.
Note that:
http://myhost.com/page
is legal, because it translates to:
GET /page HTTP/1.0
Host: myhost.com
http://www.searchenginejournal.com/linking-issues-why-a-trailing-slash-in-the-url-does-matter/13021/
http://www.alistapart.com/articles/slashforward/
URLs were initially used to model directories, so the trailing slash was required. I think if you don't have the trailing slash some webservers will not be able to find the content correctly.
Browser adds such slash automatically when requesting the URL. How it displaying in address bar it's a different story.
For example: www.adobe.com -- type it in different browsers and see how they will display it:
Firefox (Windows, 6.0.2) = http://www.adobe.com/
Google Chrome (Windows, 13.0.782.220 m) = www.adobe.com
Opera (Windows 11.51) = www.adobe.com
Internet Explorer 9 = http://www.adobe.com/
As explained by Anthony's first link, the slash is part of the address. Every domain (and not just "the vast majority") has a name resembling www.mysite.com, but this is just a domain name, not an URL. An URL is the address of a file, ie protocol+domainname+pathfile, so http://www.mysite.com/ is added the missing filename by DirectoryIndex and therefore is an URL, but http://www.mysite.com just doesn't mean anything since in this case the file path would be empty.
The fact that your browser doesn't display the boring parts of your URL is not related to your website's configuration.
If really the same browser behaves differently on different websites, I would be curious to know what browser and what websites you used.
Related
Is it possible to add trailing slash to root URL?
For example, I need https://domain.example -> https://domain.example/
https://domain.example and https://domain.example/ are the same URL - there is always a slash immediately after the hostname (at the start of the URL-path), even if you do not see it in the browser's address bar (it is present in the HTTP request).
The browser "prettifies" the URL you see in the address bar - this is not necessarily the exact URL that the browser uses in the request.
See the following question on the Webmasters stack:
https://webmasters.stackexchange.com/questions/35643/is-trailing-slash-automagically-added-on-click-of-home-page-url-in-browser
This is a relatively recent behavioral change and appears to be related only to requests which include a "Upgrade-Insecure-Requests: 1" request header.
Apache has started rewriting such requests for sites which are HTTP-only to an HTTPS URL using the default site name instead of just adding the / at the end of the requested URL.
Example: URL submitted in browser: http://www.example.com/blah
Intended redirect: 301 to http://www.example.com/blah/
Instead redirects: 301 to https://default.site.configured/blah/
This happens whether it's a named virtual on the same address as the default server or a virtual using a separate address with separate Listen directives.
I understand all the arguments in favor of the idea that everything should always be encrypted and I don't want to get into a debate about that. This site doesn't consider the tradeoffs desirable at this time.
The default site does have SSL and is configured to redirect HTTP->HTTPS, but the www.foo.com site is not configured that way and does not wish to implement SSL at this time.
Is there any way to get Apache 2.4 to disregard that "Upgrade" header and simply rewrite the URL as desired rather than altering the domain name?
After banging on this some more, I finally found the source of my woes.
This happens when you have IP based virtual hosts and did not configure a name for them using the "ServerName" directive.
tl;dr: If you are having this problem, try adding a "ServerName www.example.com" directive within the VirtualHost definition for the site and that should resolve it.
Details:
It does not happen until you encounter a URL that requires a rewrite other than adding a trailing /. (i.e. if you get a request that doesn't contain the "Upgrade-Insecure-Requests: 1" header, it only gets the trailing / added, but if you get one with that header, it also tries to rewrite the protocol to https which triggers the full URL rewrite).
In my case, the default host name had an SSL configuration, so it didn't fall back to HTTP after the rewrite or reject the rewrite as invalid.
YMMV, I did not continue to do an exhaustive test of all permutations once I found the solution.
I just notice if we append "#anydomain.com" to any URL Chrome (and also FF) redirects user to the domains appended.
For example:
http://www.google.com#facebook.com/ - Will redirect to facebook.com
http://www.facebook.com#google.com/ - Will redirect to google.com
I would like to prevent it from my website, does anyone know anything about it?
Thanks in advance!
-B.J.
Adding more info:
If I try to add a '/' before the '#', like this:
http://www.google.com/#facebook.com/
Then Google gives me 404 page not found... But my website still redirects with the '/'
The # symbol is used as part of the URI scheme to login users to a site.
If you notice, as soon as you click it says "You are about to log in Facebook.com with the username..."
Its part of the HTTP protocol. You can't really do anything about it.
Read : http://en.wikipedia.org/wiki/URI_scheme
I fix it.
The issue was in the Apache configuration, the permanent redirect I have to redirect from HTTP to HTTPS had the wrong template, it was missing a final slash '/'.
So when accessing:
http://mydomain.com/#anotherdomain.com
it was redirecting to https://mydomain.com#anotherdomain.com without the final slash, and the browser default behaviour was to redirect to anotherdomain.com without even hitting my server.
It was only about adding the slash on the redirect clause I have.
Redirect permanent https://mydomain.com/
To achieve a single layer of content delivery security, I'm looking into the possibility of obscuring a resource URL via an .htaccess RewriteRule:
RewriteEngine on
RewriteBase /js/
RewriteRule obscure-alias\.js http://example.com/sensitive.js
It would of course be implemented as:
<script type="text/javascript" src="obscure-alias.js"></script>
Because this is not a 301 redirect, but rather a routing scenario similar to that of many of our frameworks we used today, would it be safe to say that this RewriteRule adequately obfuscates the actual URL where this resource is located, or:
Can the destination URL still be found out via some HTTP header sniffing utility
Might a web browser be able to reveal the "Download URL"
I'm going to pre-answer my own questions by saying no to both since the "internal proxy" is taking place on the server-side and not on the client side if I understand it correctly: http://httpd.apache.org/docs/current/mod/mod_rewrite.html. I just wanted to confirm that when Apache goes to serve the destination URL, that it also isn't passing along information to the user agent what the URL was that it rewrote the original request as.
It depends on how you specify the redirect target.
If your http://example.com/ is running on the same server, there will be an internal redirect that is invisible to the client. From the manual:
Absolute URL
If an absolute URL is specified, mod_rewrite checks to see whether the hostname matches the current host. If it does, the scheme and hostname are stripped out and the resulting path is treated as a URL-path. Otherwise, an external redirect is performed for the given URL. To force an external redirect back to the current host, see the [R] flag below.
if the absolute URL points to a remote domain, a header redirect will be performed. A header redirect is visible to the client and will reveal the sensitive location.
To make sure no external redirect takes place, specify a relative URL like
RewriteRule obscure-alias\.js sensitive.js
Note that the sensitive JS file's URL can still be guessed.
To find out whether a request results in a header redirect, log in onto a terminal (eg. on a Linux server) and do
wget --server-response http://www.example.com
If the first HTTP/.... line (there may be more than one) is something that begins with a 3xx, like
HTTP request sent, awaiting response...
HTTP/1.1 302 Moved Temporarily
you are looking at a header redirect.
Possible using proxy throughput.
See http://httpd.apache.org/docs/2.4/rewrite/proxy.html
Also alluded to here as well: mod_rewrite not working as internal proxy
I have Apache 2.2.13 running in console mode on Windows. I have made an executable that handles requests. In a certain case, when it detects a URL pointing to a directory but has not trailing slash, it tries to redirect to the same URL with the missing slash appended. The exit-code is set to 301. Strangely enough, having this in the response header doesn't work:
Location: /cgi-bin/mycgi.exe/something/
but this does:
Location: something/
Am I doing something wrong? Or did I discover a bug in Apache? (If so, where and how should I post it best?)
Usually, 'Location' contains a full URL, including http: and the hostname. This is the case outlined by DVK.
Location: /cgi-bin/mycgi.exe/something/
This is actually something else: an internal redirect. It is defined by the CGI specification and works in some other server environments derived from CGI, such as PHP. When Location contains a 'virtual path', Apache serves up the page/script in that path straight away, without the browser knowing there was any kind of redirect.
Obviously that's not what you want as it makes no sense to do a 301 internal redirect when the browser will never see that it's a 301.
Location: something/
This, on the other hand, is nothing. It's not a full URL and it's not a virtual path as it doesn't begin with '/'. Apache doesn't know what to do with it, so it just guesses that it isn't a virtual path so spits it back to the browser with no further comment.
It's invalid to send this in a 'Location' header to a browser, but many of them will allow it anyway, which is why it appears to work. Really you should be passing the full URL:
Location: http://www.example.com/cgi-bin/mycgi.exe/something/
1) Just to be clear, the redirection functionality (e.g. "what to do when seeing "Location: http response) is in your browser, not in Apache. I assume you know that but wanted to make sure it's clear. The reason it's relevant here is because as per the RFC, the address in 301 response needs to be "a single absolute URI". So your URI example is missing your domain name, e.g. needs to be http://your.web.server/cgi-bin/mycgi.exe/something/
While some web clients accept 301 with relative redirect, others do not.
2) Can you please specify exactly what you mean by "does not work" including client's error and any errors in Apache's log? Thanks
Also, please specify which of the following URLs work from the client and which do not:
http://your.web.server/cgi-bin/mycgi.exe/something/
http://your.web.server/something/
http://your.web.server/cgi-bin/mycgi.exe/something
Thanks