Relative link (from https) gives 301 Permanently Moved (to http)
I own a domain name (let's call it example.org ), and have set up a CNAME pointing from foo.example.org to an AWS ELB FooBar-Load-Balancer-123456789.us-east-1.elb.amazonaws.com . That ELB has a Port Configuration of 443 (HTTPS, ACM Certificate <GUID>) forwarding to 80 (HTTP) . The sole EC2 instance behind the ELB runs a Docker image exposing Apache on port 80.
When I open https://foo.example.org in my web browser, everything works fine - the page loads as expected. If I navigate to https://foo.example.org/path , it likewise loads correctly. However, if a page contains <a href="path"> , upon clicking that the browser attempts to load http://foo.example.org/path , which (correctly) gives an error - "ERR_CONNECTION_REFUSED" in Chrome, "Unable to connect" in Firefox.
Checking the network activity in Chome Dev Tools, I see an initial request to https://foo.example.org/path which results in 301 Moved Permanently (from cache) with Location http://foo.example.org/path . This is obviously what's causing the browser's behaviour - is this misconfiguration on my server (which believes itself to be serving on HTTP - or, at least, port 80), on my ELB, or on the site's html itself?
I guess I could get around this by using absolute paths, but, given that I want to be able to spin up a Docker image locally (opening <IP Address>/path in my browser) to test before pushing changes, that doesn't sound like a true solution.
EDIT: Inspired by this, I checked behaviour in a fresh Chrome Incognito Mode window and in Chrome after clearing history - same behaviour in all cases.
Posting this as an answer since I'm technically unblocked, although I'd still very much appreciate someone more knowledgable explaining why these symptoms occurred.
A bit of investigation with curl led me to this:
$ curl -v https://foo.example.org/path
* Trying 52.0.230.252...
* Connected to foo.example.org (52.0.230.252) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: example.org
* Server certificate: Amazon
* Server certificate: Amazon Root CA 1
* Server certificate: Starfield Services Root Certificate Authority - G2
> GET /path HTTP/1.1
> Host: foo.example.org
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html; charset=iso-8859-1
< Date: Sun, 05 Jun 2016 18:35:58 GMT
< Location: http://foo.example.org/path/
< Server: Apache/2.4.7 (Ubuntu)
< Content-Length: 336
< Connection: keep-alive
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://foo.example.org/path/">here</a>.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at foo.example.org Port 80</address>
</body></html>
* Connection #0 to host foo.example.org left intact
$ curl https://foo.example.org/path/ # Note trailing slash
<expected html>
So it looks like making a request to apache for a directory without a trailing slash ("Directories require a trailing slash, so mod_dir issues a redirect to http://servername/foo/dirname/. "). That explains why the Location header in the 301 response used http:// - apache was serving http:// , so "knew no better". I guess I can solve this by making my anchor tags explicitly link to a href with a trailing slash.
Why is Apache configured this way? Why not just automatically resolve to the appropriate location "internally", without having to make a round-trip of the 301 response? And, most importantly - is there a better way for me to solve this problem? Can ELB's be configured to rewrite Location headers (I guess not - I'm not InfoSec pro, but that strikes me as a vulnerability waiting to happen)? Can Apache?
链接地址: http://www.djcxy.com/p/41296.html上一篇: 服务器不提供图像