I have a Laravel app running on Fortrabbit. All it's routes are an API (except for /). The frontend talks to the backend via the API. The frontend is served via https, as are all the routes.
Everything works via https: the assets, the API calls. All except for one route that redirects it's requests to http. It's a search function so at first I thought it might be the client-side library I'm using for the search but if I copy the XHR request as CURL and fire it from my terminal, I also get the redirect:
Request:
curl 'https://theapp/?search=mak' -H 'Accept: application/json, text/plain, */*' -H 'Referer: https://theapp/' -H 'X-XSRF-TOKEN: the-token -H 'X-Requested-With: XMLHttpRequest'
Response:
<!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 here.</p>
<hr>
<address>Apache/2.4.25 (Ubuntu) Server at theapp Port 80</address>
</body></html>
I'm not a Laravel pro but I can't see or find anything that would cause that behaviour, whether in the configs or .htaccess. The APP_URL is set to the https URL as well.
Like I said there are several other GET routes in the app that do not redirect.
I contacted the Fortrabbit team but they insist they aren't redirecting anything to http. I don't see anything in the logs either, other than the request.
Does anyone have an idea what could be causing this?
One thing I notice is that the new URL in the redirect is missing the / after theapp. Perhaps this was just an error when you made it anonymous.
I suggest examining logs to see where this is being generated. For mod_rewrite add LogLevel rewrite:trace3 to your main config and review the error log. If it's being done by mod_alias then that will appear in the usual Apache access logs as a 301.
Related
I'm hosting my git-hub pages website (peps09791.github.io) using a custom domain (https://thebotspeaks.com) with Cloudflare.
To enable HTTPS, I have done the following configurations:
In my _config.yaml file
I have set the URL key accordingly
url: "https://peps0791.github.io"
From my cloudFlare dashboard, I have enabled option of HTTPS rewrites to prevent mixed content error.
I have also enabled Flexible SSL from CloudFlare.
I haven't enabled default HTTPS-redirection because the website breaks over HTTPS. On HTTP, it works fine.
Right now, when I try to access my website using HTTPS, I get mixed content error:
Mixed Content: The page at 'https://thebotspeaks.com/' was loaded over HTTPS, but requested an insecure image 'http://thebotspeaks.com/assets/images/bio-photo.jpg'. This content should also be served over HTTPS.
09:54:45.323 (index):1 Mixed Content: The page at 'https://thebotspeaks.com/' was loaded over HTTPS, but requested an insecure stylesheet 'http://thebotspeaks.com/assets/css/main.css'. This request has been blocked; the content must be served over HTTPS.
09:54:45.785 (index):1 Mixed Content: The page at 'https://thebotspeaks.com/' was loaded over HTTPS, but requested an insecure script 'http://thebotspeaks.com/assets/js/main.min.js'. This request has been blocked; the content must be served over HTTPS.
From console, I can see this:
<script src="https://peps0791.github.io/assets/js/main.min.js"></script>
<link rel="stylesheet" href="https://peps0791.github.io/assets/css/main.css">
How do I resolve this issue?
The problem here is that your assets (i.e. your CSS or JavaScript) are redirecting to the HTTP version of your site. This is because your assets are referencing directly to your GitHub site instead of the Cloudflare-enabled domain.
For example; your HTML references your CSS files at https://peps0791.github.io/assets/css/main.css instead of https://thebotspeaks.com/assets/css/main.css
In order to fix this it looks like you'll need to update your _config.yaml file to have the following URL key:
url: "https://thebotspeaks.com"
More general advice on fixing a variety of Mixed Content issues can be found in the following article on the Cloudflare Knowledge Base: How do I fix the SSL Mixed Content Error Message?
Adding this helped me to deal with the Mixed Content error on GitHub pages on a custom domain secured with enabled HTTPS:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
Apparently for me. The website inside CNAME file in Github repo did NOT had https prefix. So I added https://. and it worked.
Cheers
P.S: Fixed this problem after 1 year, can you believe.
I can upload a file using cURL command in the following way,
curl --upload-file file_name http://example.com/upload/
Web server is Apache. It has a directory "upload" already created.
But when I do the following it fails,
curl --upload-file file_name http://example.com/upload/subdirectory/
cURL reports the following error,
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /upload/subdirectory/file_name
on this server.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at example.com Port 80</address>
</body></html>
My requirement is to let cURL create a directory with "subdirectory" under "upload" and copy the file "file_name".
I guess it is to do something in Apache config file.
Any idea.
You're right you probably have some kind of Apache redirect setup - but even then you'rs going to still need some kind of php file to process your put request. That's not something curl can do on the client side.
UPDATE:
Mixed Content: The page at 'https://myapp.herokuapp.com/#/employees'
was loaded over HTTPS, but requested an insecure XMLHttpRequest
endpoint
'http://api.geonames.org/countryInfoJSON?username=design1online'. This
request has been blocked; the content must be served over HTTPS.
I'm trying to call the below api from one of my app in heroku and I'm getting the below error
Do I need to add-on SSL?
I have even tried without http: something like this:
//api.geonames.org/countryInfoJSON?username=design1online
API call:
http://api.geonames.org/countryInfoJSON?username=design1online
Error:
failed to load resource: net::err_ssl_protocol_error
adding S to the http tag actually worked for me, I just had the issue today
<script src="https://maps.googleapis.com/maps/api/js?region=GB"></script>
I'm running Magento Enterprise 1.9 with APC caching on Apache (Debian).
If I browse to a non-existent URL on my site, I receive a 404 response from the server and am presented with my 404 page as expected. However, if I then visit that same URL again, this time (and all subsequent times) I receive a "200 OK" status from the server, despite the URL still being invalid and the 404 page still being presented.
Examples:
$ curl -I http://www.example.com/some-nonexistent-URL
$ HTTP/1.1 404 Not Found
$ curl -I http://www.example.com/some-nonexistent-URL
$ HTTP/1.1 200 OK
I am assuming that this is because the resposne to that URL is being cached somehow so the server sends out a "200 OK" cached version of the 404 page (!).
How can I prevent this?
This was Magento's Full Page Cache fault.
I discovered Magento checks for the presence of a cookie called NO_CACHE, so I just put $_COOKE["NO_CACHE"] = true; at the point before the 404 action is called (in my case, /app/code/core/Mage/Cms/controllers/IndexController.php).
I also added a cache-control: no-cache, must revalidate header, and the same cookie as above into the 404 page template itself for good measure.
When you configure Apache to do a redirect, by default it outputs not just the Location header but also some content, presumably for the benefit of user agents which do not support the Location header:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>301 Moved Permanently</TITLE>
</HEAD><BODY>
<H1>Moved Permanently</H1>
The document has moved here.<P>
<HR>
<ADDRESS>Apache/1.3.37 Server at example.com Port 80</ADDRESS>
</BODY></HTML>
Is this necessary? Is there any user agent, anywhere, that I need to worry about that won't understand a Location header and a blank body?
I suspect not, as example.net itself outputs a blank body. In that case, why does Apache do this?
A number of programmatic tools for accessing websites will not follow redirects by default without explicit configuration. Returning content like this makes it a lot easier to diagnose problems caused by not following a redirect. For example, curl, commonly used in scripts, will only follow redirects if you pass it the -L option.