Non-Authoritative-Reason header field [HTTP] - google-chrome

I'm having difficulty finding out what it means when I have the response header Non-Authoritative-Reason : HSTS
I have searched a lot but just came up with some explanations about HSTS (redirection from HTTP to HTTPS). Can anyone help me with that? By the way I'm using Chrome.
Thanks

The server you are trying to connect with uses strict-transport-security (HSTS) to ensure https only is used with this site rather than the default http.
This means if you enter http://www.servername.com then Chrome will automatically convert this to https://www.servername.com.
This is a security feature to prevent use of http, which is unencrypted and which can be read and altered by a hacker. This can be set by the server telling Chrome (via a special HTTP Header sent in response to requests) that it uses HSTS. This setting is then cached by Chrome for the given amount of time as defined in the max-age value in that header. Additionally the site owner can submit their site to a preload list that is automatically included in Chrome - which protects even the first visit as normally you need to visit the site to receive the header to activate this.
The way Chrome shows this in the network tab is by creating a dummy 307 response with a redirect to the https version of the address. But that's a fake response and is not generated by the server - the reality is Chrome did that internally before the request even went to the server.
To clear this setting for a site you can type the following into Chrome's URL field: chrome://net-internals/#hsts and then search for your site and delete it. You may also set this at a top level domain and include subdomains so you may need to delete from there. Alternatively you can just alter your server config to publish the header with a max-age of 0 and revisit the site to clear this, then stop publishing the header, which can be helpful for other browsers where it's not quite as easy to clear this.
Note you cannot clear this setting if a site is on the preload list as this is embedded in the web browser's code. The site owner can submit a request to be removed from the preload list but this takes several months to go through the release cycle for Chrome and no defined timeline for other browsers. Chrome also provides no way to override preloaded settings - for security reasons.

Some additional info to BazzaDP's answer...
The Non-Authoritative-Reason : HSTS returned in the response is not something you have configured, but rather Chrome itself. Since Chrome hijacks the request, Chrome will also add this particular header to tell HSTS is enabled. Looking at the network tab, you will see the fake 307 response with this header set.
All this is done since you included the Strict-Transport-Security header on your server.
If you want to go all in, here's the HSTS preload list

According to MDN (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security):
The Strict-Transport-Security header is ignored by the browser when
your site is accessed using HTTP; this is because an attacker may
intercept HTTP connections and inject the header or remove it
And the HSTS Preload list deployment recommendations mention:
Add the Strict-Transport-Security header to all HTTPS responses
The HTML5 Boilerplate shows how to only set Strict-Transport-Security over HTTPS (in apache):
# Set 'Strict-Transport-Security' over HTTPS only!
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ %{ENV:PROTO}://%1%{REQUEST_URI} [R=301,L]
</IfModule>

Related

IPFS X-Ipfs-Path on static images referenced on a dynamic non-IPFS https page forces localhost gateway to load over https

I'm trying to utilize IPFS to load static content, such as images and javascript libraries, on a dynamic site loaded on the http protocol.
For example https://www.example.com/ is a normal web 2.0 page, with an image reference here https://www.example.com/images/myimage.jpg
When the request is made on myimage.jpg, the following header is served
x-ipfs-path: /ipfs/QmXXXXXXXXXXXXXXXXX/images/myimage.jpg
Which then gets translated by the IPFS Companion browser plugin as:
https://127.0.0.1:8081/ipfs/QmXXXXXXXXXXXXXXXXX/images/myimage.jpg
The problem being, is that it has directed to an SSL page on the local IP, which won't load due to a protocol error. (changing the above from https to http works)
Now, if I were to request https://www.example.com/images/myimage.jpg directly from the address bar, it loads the following:
http://localhost:8081/ipfs/QmYcJvDhjQJrMRFLsuWAJRDJigP38fiz2GiHoFrUQ53eNi/images/myimage.jpg
And then a 301 to:
http://(some other hash).ipfs.localhost:8081/images/myimage.jpg
Resulting in the image loading successfully.
I'm assuming because the initial page is served over SSL, it wants to serve the static content over SSL as well. I also assume that's why it then uses the local IP over https, rather than localhost in the other route.
My question is, how do I get this to work?
Is there a header which lets IPFS companion to force it to load over http? If so, I'm assuming this would cause browser security warnings due to mixed content. I have tried adding this header without luck: X-Forwarded-Proto: http
Do I need to do something to enable SSL over 127.0.0.1, connecting this up with my local node? If so, this doesn't seem to be the default setup for clients, and worry that all the content will show broken images if they do not follow some extra steps.
Is it even possible to serve static content over IPFS from non-IPFS pages?
Any hints appreciated!
Edit: This appears to effect the Chrome engine and and Firefox.
Looks like a configuration error on your end.
Using IPFS Companion with default settings on a clean browser profile works as expected.
Opening: https://example.com/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi redirects fine to http://localhost:8080/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi which then redirects to unique Origin based on the root CID: http://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi.ipfs.localhost:8080/
You use custom port (8081), which means you changed the Gateway address in ipfs-companion Preferences at some point.
Potential fix: go there and make sure your "Local gateway" is set to http://localhost:8081 (instead of https://).
If you have http:// there, then see if you have some other extension or browser setting forcing https:// (check if this behavior occurs on a browser profile, and then add extensions/settings one by one, to identify the source of the problem).

Some images/icons not working on 1st load

Not loading few icons when it loads 1st time at any browser in OpenCart 2.0.3.1, also add to cart button dose not works at 1st time load.
Site URL- http://www.allcardecor.com/
I tried clearing my cache, reinstalling all my modules.
You're having a cross-domain issue with your request. When I load that page in my console I see this error:
Font from origin 'http://allcardecor.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.allcardecor.com' is therefore not allowed access.
You'll note that your site http://www.allcardecor.com, is calling on the FontAwesome files from http://allcardecor.com. The browser is seeing this as two different domains.
You'll want to setup a canonical name for one of the domains in your DNS so that it's recognized as a legitimate alias for the other.
https://en.wikipedia.org/wiki/CNAME_record
You should also setup CORS so that you can call scripts from approved sites without running into cross domain errors:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
For someone who might still need this. The problem is due to cross domain issue as Jocko has pointed out.
Another way to fix this is to redirect all requests to your site to particular subdomain, e.g. yourdomain.com => www.yourdomain.com and link all resources as such.
On Apache, in .htaccess file, add the following lines:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain.com [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [L,R=301]
On Nginx, checkout this link.

XMLHttpRequest cannot load. Unloaded resources show caution: Provisional headers are shown

I actually don't know the right title for this question, because of I've found many similars but still couldn't figure the solution out.
My problem is that (on Chrome) the website I've working on remain showing console log: XMLHttpRequest cannot load http://resource.domain.com/file.css. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.my-site-url.tld' is therefore not allowed access.
I've tried to allow that resources via .htaccess files using this code.
<FilesMatch "\.(jpg|jpeg|png|gif|js|css)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin http://wp.com,http://ajax.googleapis.com,http://fonts.googleapis.com,http://zor.fyre.co
Header set Access-Control-Allow-Credentials true
</IfModule>
</FilesMatch>
Doesn't work. I've also tried php and jsonp version.
Anyone please help me to fix this issue.
Additional info:
Lately, in inspect elements > Networks > Headers section, I found this message:
Your issue most likely stems from the fact that you are trying to load content from an external domain, which is prohibited in a normal json call hence the No 'Access-Control-Allow-Origin' error. The technique you may need is known as JsonP. I would link the documentation; however, it really can depend on the javascript framework you are using. I recommending reviewing this post for a walk-through on how to invoke this behaviour via normal JS. https://stackapps.com/questions/891/how-to-call-the-api-via-jsonp-in-plain-old-javascript
Hope this helps!

WWW and non-WWW URL. Two different sites

I just noticed today that a website I am creating has the WWW or non-WWW problem. If you go to http: //www.taskconductor.com, it is a different page with the same content as just http: //taskconductor.com.
If you were to login (username: show#412customs.com, Pass: tester) at http: //www.taskconductor.com, then try to go to http: //taskconductor.com (without the WWW), it will make you log in again. Then as you can see, when you check your cookies, you can see that there are two sets of cookies. One for http: //taskconductor.com and one for http: //www.taskconductor.com.
I have seen that this is a problem, but do I need to make a redirect? and if so, does it have to be index.php? I would really prefer to have all of my main content on index.php.
How can I get around this?
Do you know what web server you are using? If you're using apache, you can rewrite the URL in the .htaccess file. This will allow you to funnel all your traffic to with your non-www domain. I did a quick google and found this sample code:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.example.com$ [NC]
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]
Source: http://yoast.com/how-to-remove-www-from-your-url-with-mod_rewrite/
I was able to set my php "setcookies" to have a specified domain.
My original setcookie string was: setcookie('ver_ame', $email, time()+2592000);
This only allowed the cookie to be set on whatever type of page it was on. If it were on http: //taskconductor.com it would set the cookie for that, and also the same if it were http: //www.taskconductor.com.
If your setcookie string is: setcookie('ver_ame', $email, time()+2592000, "/", ".taskconductor.com");
The additional "/" shows the cookie to work on any of the directories under the root. The ".taskconductor.com" part would be showing which domain to use. The fact that it has a period before the web name shows that this cookie will work on any subdomain or its own domain.
Thank you all for the responses and help! It all works now! THANK YOU!
Better than using URL rewrites is to set your cookies to work for subdomains. For example, if you set the cookie for mydomain.com, then it will not work for sub.mydomain.com. However, if you set the cookie for .mydomain.com (notice the period), then it will work for mydomain.com, sub.mydomain.com, foobar.mydomain.com etc.
If you explicitly set your cookie domain to taskconductor.com (no www), then the same single set of cookies will be used for both the www and the naked domain. You'll just need to modify your PHP to specify a cookie domain.
I would recommend you do as others are suggesting and do a redirect to whichever version you want to use as the canonical URL. It's bad practice to have duplicate content across multiple (sub) domains. But, it's also a good idea to understand the domain scope of cookies that you set.

Temporary way to convert base urls in HTML

Right now I have a website with all the href and src point to /some/url. There's always a slash in the beginning.
I'm currently testing the site using a subdirectory on the server, which has the address of http://somedomain.com/subdirectory/ (production would be http://somedomain.com)
Is there anyway to temporarily convert the /some/url from http://somedomain.com/some/url to http://somedomain.com/subdirectory/some/url without actually changing each of the href and src properties. From what I can make out of the base tag, it doesn't work like that. Also changing the RewriteBase from / to /subdirectory also doesn't work (Not too familiar with mod_rewrite, maybe someone can fill me in on that)
in .htaccess file in somedomain.com dir U can put:
Options +FollowSymLinks
RewriteEngine On
RewriteRule (.*) http://somedomain.com/subdirectory/$1 [r=301,nc]
I haven't tried it, but mod_proxy_html might be able to do this. From the documentation:
mod_proxy_html is an output filter to
rewrite HTML links in a proxy
situation, to ensure that links work
for users outside the proxy. It serves
the same purpose as Apache's
ProxyPassReverse directive does for
HTTP headers, and is an essential
component of a reverse proxy.
For example, if a company has an
application server at
appserver.example.com that is only
visible from within the company's
internal network, and a public
webserver www.example.com, they may
wish to provide a gateway to the
application server at
http://www.example.com/appserver/.
When the application server links to
itself, those links need to be
rewritten to work through the gateway.
mod_proxy_html serves to rewrite foobar
to foobar
making it accessible from outside.