I have just converted an HTML template to php. I have put the folders like css,js,and images at the root directory of codeigniter project. Using base_url function I have successfully fetched images and styles yet some of the icons are still missing and I am getting this error in console
Access to font at 'http://[::1]/diz/fonts/themify.woff?-fvbane' from origin 'http://localhost' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I have also put this line in my controller that loads the view of index page
header('Access-Control-Allow-Origin: *');
I expected it to solve the problem but it is not doing anything. I have also tried answers given by others here, but it did not help.
Thanks in advance
The response header in network is :
HTTP/1.1 200 OK
Date: Wed, 06 Nov 2019 10:32:51 GMT
Server: Apache/2.4.33 (Win32) OpenSSL/1.1.0h PHP/7.2.6
Last-Modified: Tue, 12 Mar 2019 09:38:36 GMT
ETag: "db2c-583e27406bf00"
Accept-Ranges: bytes
Content-Length: 56108
Content-Type: font/woff
Try to use
header('Access-Control-Allow-Origin: *');
header("Access-Control-Allow-Methods: GET, OPTIONS");
If it not works u can try to configure your local server
Apache:
<FilesMatch ".(ttf|otf|eot|woff|woff2)$">
<IfModule mod_headers.c>
Allow from all
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
and Nginx:
if ($filename ~* ^.*?\.(eot)|(ttf)|(woff)$){
add_header Access-Control-Allow-Origin *;
}
Related
My frontend is trying to fetch() an image from my API, which usually handles my CORS. Because it directly requests the image, circumventing the API, I receive this issue: (which makes complete sense why)
Access to XMLHttpRequest at 'https://my-api.test/storage/media/1/15/poster.jpg' from origin 'http://localhost:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I need to adjust my Nginx settings so that any file requested living under the /storage/ path will have this header added.
I must be misunderstanding parts of how I should configure Nginx in this case, because I was believing that this location-block should have worked:
location /storage/ {
add_header 'Access-Control-Allow-Origin' '*';
}
Oddly, it returns a "404 status":
curl -I https://my-api.test/storage/test-media/butterfly.jpg
HTTP/2 404
server: nginx/1.19.4
date: Tue, 17 Nov 2020 06:57:23 GMT
content-type: image/jpeg
content-length: 116501
etag: "5f6045f4-1c715"
On the other hand, if I disable the location-block condition:
#location /storage/ {
add_header 'Access-Control-Allow-Origin' '*';
#}
The header then is properly added:
curl -I https://my-api.test/storage/test-media/butterfly.jpg
HTTP/2 200
server: nginx/1.19.4
date: Tue, 17 Nov 2020 07:00:53 GMT
content-type: image/jpeg
content-length: 116501
last-modified: Tue, 15 Sep 2020 04:41:24 GMT
etag: "5f6045f4-1c715"
access-control-allow-origin: *
accept-ranges: bytes
Any help would be truly appreciated!
edit 1
I am not sure whether it makes a difference, but the "storage" folder is a symlink.
edit 2
The nginx error:
2020/11/17 12:45:50 [error] 64990#0: *1 open() "/storage/media/1/1/turtle.jpg" failed (2: No such file or directory), client: 127.0.0.1, server: , request: "HEAD /storage/media/1/1/turtle.jpg HTTP/1.1", host: "my-api.test"
When I try to visit the URL in the browser my-api.test/storage/media/1/1/turtle.jpg it returns the image and not a 404.
The solution to this problem was rather simple:
location /storage/ {
root '/Users/chrisbreuer/code/my-api/public';
add_header 'Access-Control-Allow-Origin' "*" always;
}
As you can see, the location-block is now adding a root which is where the "storage" folder lives in.
In my case, I was using Laravel Valet and when you have a secure site, you would need to adjust the nginx config file which is located in this path: ~/.config/valet/Nginx/meema-api.test.
Now, simply run valet restart and all files requested from within the storage-folder will have the header included.
I am currently outputting some image files via PHP's readfile() using the following code but, I notice via Firefox and Chrome's dev tools that none of these files get cached.
ob_start();
outputfile($fp);
function outputfile( $fp ) {
header("Content-Type: $mime_type");
header("Content-Length: " . filesize($fp));
header("Cache-Control: public, max-age=3600");
header("Etag: " . md5_file($fp));
$date = gmdate("D, j M Y H:i:s", filemtime($fp))." GMT";
header("Last-Modified: $date");
readfile($fp);
exit; // tried ob_end_flush() too before exiting
}
The code outputs the file with the following in the headers in the dev tools...
Cache-Control: public, max-age=2678400
Connection: keep-alive
Content-Length: 155576
Content-Type: image/jpeg
Date: Mon, 21 May 2018 22:31:02 GMT
Last-Modified: Sat, 03 Mar 2018 19:34:05 GMT
Etag: 507f2520385c009a7385a1165032bd61
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Server: nginx
If I return control to Nginx to serve the file instead, it outputs the following headers:
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 155576
Content-Type: image/jpeg
Date: Mon, 21 May 2018 22:31:02 GMT
ETag: "5a9af8ad-4a5b"
Last-Modified: Sat, 03 Mar 2018 19:34:05 GMT
Server: nginx
Am I missing something that causes the browsers to not cache the image files?
I've tried adding all the necessary Cache-Control headers such as eTag and max-age but, the browsers just refuses to cache the data. I even tried copying all the headers from the server's output and using "ob_start('ob_gzhandler');" in case it was because the raw file data wasn't gzipped.
The browsers just won't cache any file data sent through PHP.
Expires: Thu, 19 Nov 1981 08:52:00 GMT could be the cause. Technically if the Cache-Control header has a max-age directive then Expires should be ignored (Ref : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires). However it is worth checking by removing that header.
Your PHP code is not setting it. So I assume it is coming from some common config / code which gets executed on every outgoing response. Have you put this in your Nginx config for all PHP requests?
I think I've found the problem...
Was wondering if any cookie related code could affect readfile() and discovered that if I had session_start() before using the function, browsers will refuse to cache the file data sent. If I remove session_start() the browser caching works as expected respecting the Cache-Control headers sent.
I don't quite understand why this is the case since I compared the output of readfile() with and without session_start() before it and the output seems to be the same.
For the record I'm using PHP 5.5.
I created simple react app as described in https://reactjs.org/docs/add-react-to-a-new-app.html and now want to make AJAX calls to the webserver (with PHP). To make it working with development server at localhost:3000 I am trying to set up proxy in package.json
"proxy": {
"/abc": {
"target": "http://web.local/app/path/public/abc",
"secure": false,
"changeOrigin": true,
"logLevel": "debug"
}
}
Unfortunately app answers with default index.html content. How to make proxy working when requesting /abc path?
Is there any way to test and debug proxy? When I try to open http://localhost:3000/abc I can see
[HPM] POST /abc/abc -> http://web.local/app/path/public/abc
in console. But there is no messages when I'm loading app and request is sent from the app. (I tried fetch and axios calls.)
When I build app and run it on web server, all works fine.
EDIT:
Response Headers for the axios ajax call:
HTTP/1.1 404 Not Found
X-Powered-By: Express
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Content-Length: 143
Vary: Accept-Encoding
Date: Wed, 03 Jan 2018 17:44:02 GMT
Connection: keep-alive
For fetch:
HTTP/1.1 301 Moved Permanently
X-Powered-By: Express
Content-Type: text/html; charset=UTF-8
Content-Length: 165
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Location: /abc/
Vary: Accept-Encoding
Date: Wed, 03 Jan 2018 17:58:37 GMT
Connection: keep-alive
And
HTTP/1.1 200 OK
X-Powered-By: Express
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
ETag: W/"649-W8GnY7MkgPFg6/GXObpRHPnVDeU"
Vary: Accept-Encoding
Content-Encoding: gzip
Date: Wed, 03 Jan 2018 17:58:37 GMT
Connection: keep-alive
Transfer-Encoding: chunked
I resolved issue. My php files were located in public/ dir of the app (to have them included in build). And it is accessible from development web server as static content. Now proxy checks if file exists in public/ and delivers it if possible. And if there is no such file, then rules are applied and it tries to fetch data from specified URL.
So I moved all php related files to other location and needed data are delivered from web server through proxy as inteded just with
"proxy": "http://web.local/app/path/static"
in package.json.
Also I had to add separate command to copy content of this dir to build/ and add it to build process.
I have the following code which I am using for my website. I would like to know if this code is correct in order for me to effectively cache me pages and files. I have tried to use tools to check this but some say they don't see that I am caching.
<ifModule mod_headers.c>
# 1 Month
<filesMatch ".(ico|gif|jpg|jpeg|png|pdf)$">
Header set Cache-Control "max-age=2419200"
</FilesMatch>
# 1 Week
<filesMatch ".(css|js)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>
# 1 Day
<filesMatch ".(htm|html)$">
Header set Cache-Control "max-age=86400"
</FilesMatch>
</ifModule>
Catching is the automatic mechanism of the browsers. When a page is loading, browser checks the cache for static files like js, css, images..., if they are not available browser will pus them into cache.
To determine whether the file is cached or not, check the firebug console and clik on request link.
here you can see information like
Accept-Ranges bytes
Cache-Control max-age=290304000, public
Content-Encoding gzip
Content-Length 2824
Content-Type application/javascript
Date Thu, 11 Jul 2013 10:15:06 GMT
Expires Fri, 12 Jul 2013 10:15:06 GMT
Last-Modified Thu, 03 Jan 2013 16:05:54 GMT
Server Apache
Vary Accept-Encoding,User-Agent
I'm using PHP 5.3 and Apache 2.0 to serve a script which adds a number of headers to the output:
header('HTTP/1.1 200 OK');
header("Content-Type: application/json");
header("Last-Modified: $lastmode"); // $lastmod = Tue, 01 Mar 2011 14:56:22 +0000
header("Etag: $etag"); // Etag = 5da02274fcad09a55f4d74467f66a864
Now, all the headers come through except for the Last-Modified and Etag. In my httpd.conf I have the following:
Header unset Cache-Control
Header unset Pragma
But in my response I get:
HTTP/1.1 200 OK
Date: Tue, 01 Mar 2011 16:49:10 GMT
Server: Apache/2.2.14 (EL) mod_ssl/2.2.14 OpenSSL/0.9.8e-fips-rhel5
Keep-Alive: timeout=15, max=8000
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/json
Expires: 0
Cache-Control: no-cache
My Last-Modified and Etag headers are gone and we have Cache-Control and Expires in their place.
I should also mention that I have disabled mod_expires to no avail. I am pulling my hair out at this point as no matter what I do the headers are simply not there. What could possibly cause them to be removed?
Thanks,
J
UPDATE: It seems that Apache is adding the additional headers after PHP has shutdown and I would think it's also removing the headers I set above. Registering a shutdown function in PHP and calling apache_response_headers shows:
Pragma=
Expires=
Etag=5da02274fcad09a55f4d74467f66a864
Last-Modified=Tue, 01 Mar 2011 14:56:22 +0000
Keep-Alive=timeout=15, max=8000
Connection=Keep-Alive
Transfer-Encoding=chunked
Content-Type=application/json
To answer my own question it seems that the tool I was using to debug was giving me the grief. It was the mod_expires module causing the problem in the first place but the reason that removing it had no effect was that the proxy I was using to debug the problem (Charles) seems to modify the headers. Once Charles was taken out of the loop my headers were there!