I have a background image for a website. Using PNG it works just fine. I created a .webp file using cwebp and the .webp file displays just fine locally in Preview or in Chrome. The website using it is served as static files using NGINX in a container that happens to be hosted in Azure. I can access the site and the background image via Azure Front Door or on an exposed IP. I have tried with GZIP on and off (NGINX config and Azure FD Config). If I serve the image running the react scripts locally it works.
But in all cases when running in a container in K8s on Azure, the PNG file works fine but the WEBP file fails to display - sometimes you get a brief flash of a corrupted image as it loads. Examining the file after downloading it has a different length.
It appears that NGINX is corrupting the file. The NGINX conf line that serves the file is the simplest possible try_files $uri /index.html;. I have proxy_http_version 1.1; and the image is served with the correct mime type.
As you can see below the file retrieved by the browser is 3,653,289 bytes but the file being served should be 3,653,334 bytes.
It turns out that the culprit was in fact the cwebp tool from Google. Using a different tool to create webp files has created files that work just fine.
It's still a mystery why the files worked locally in Preview and Chrome, but not when copied to a web server maybe it's related to the length issues others have reported in webp file corruption?
Related
Locally I got:
The deployed version I got:
I'm not sure why the service URL is added before the image URL.
And the wired thing is the dynamic url path does not load correctly while the static path works well.
I guess it might have to do with the path redirection so below is my setting:
We are having an issue getting our favicon to show up. Little background on the app setup. The application is a React app that is served up by Nginx. We did have to make a change to the default.conf file to add a location block to for an alias with the path to the favicon to get it working in Docker. So, from Docker the favicon now shows up just fine when ran locally, but when deployed to our K8s the favicon no longer shows up. I did test with private mode/incognito to make sure it wasn't a caching issue.
Favicon is located in the root of the app along side the index.html.
I haven't been able to find anything that has really helped with resolving this issue, but I do believe I need to reference either the nginx's conf file or the favicon in the deployment yaml.
Has anyone ever dealt with something similar to this before or have any ideas?
Turns out for this scenario. Since the browser tab was opened by another application, it was the path to that apps favicon I needed. For some reason it was trying to look in that folders directories. Doesn't make a lot of sense why it would to me but it is better to have one source.
Github pages, set up to serve main -> / (root), refuses to serve actual markdown files.
Github will serve <domain>/v1/blog/Home (as Jekyll) but will give a 404 error when serving <domain>/v1/blog/Home.md.
It doesn't matter if the file is requested with javascript or by a browser, it isn't provided.
Other files, github has no problem serving (<domain>/v1/index.html, <domain>/v1/js/main.js, <domain>/v1/css/style.css.
Additionally, the markdown file located in <domain>/v1/blog/sidebar/mainSidebar.md is served just fine.
I have not tested markdown files in / (root).
I have tested this with Firefox and Google Chrome.
Link which gives 404 error: Https and Http
Proof that file exists: Https and Http
Proof that markdown files are fetched just fine in other github pages sites: Http
Proof that github is serving the correct branch:
EDIT: Currently troubleshooting this by changing directory names, etc. As such the links above won't work.
I installed WP locally on XAMPP.
When I manually type my project root in a browser I start seeing this. But when I run the project through VScode Live server I start seeing all files and directories of my site see here.
Why does this happen? Is it because I run the project locally? Or is it because the root is followed by :5050 port number?
My theme style.css is empty.
My theme index.php contains only starting html !+tab attributes (see here)
The first image looks like to be served by apache which loads mod_php which "executes" the php code of every .php file and serve the result as html.
The second image looks like an application running on port 5000 (which might not be apache) and NOT using a module to "execute" .php file so it just shows the content of the folder.
My version of Jekyll on Ubuntu Linux is not adding the correct mime type to a .css file in the _site/css/ directory. I found this out because it causes errors when uploading site to AWS S3 bucket and the site won't render properly.
Here is what I've done:
created a new jekyll site jekyll new s3upload
build the site jekyll build
serve the site jekyll serve
and it serves fine, renders correctly in the browser, however the newly created file, main.css in _site/css directory has a mime type set as text/plain. If I then upload it to an amazon web services bucket, to be served it fails because it needs the mime type to be set correctly to text/css.
Is this a bug in Jekyll, or how can I correct it so it creates the new .css file with the correct text/css mime type?
Relative noob here.
Jekyll doesn't care about mime types.
It's server's job.
If you jekyll serve, load the page in your favorite browser, hit f12 -> network, you will see that your css is served as text/css by WEBrick web server.
Now, in your file explorer, file->properties, you see that your css has a text/plain mime type. It is operating system point of view. This has nothing to do with serving the file.
Nevertheless, you can try to :
Open /etc/mime.types
Look for the line : text/css css
If it doesn't exists, add it.
Do a jekyll build Reload to AWS bucket
If AWS still serve your css as text/plain, the problem is on the AWS side and you can start googling about aws bucket mimetype problem, see Amazon S3 is not serving files correctly