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.
Related
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?
I've built out a new site in Next.js and have deployed it on vercel.com (their free Hobby plan).
Everything works except that I built out some sample pages and put them into /public (as instructed by the Nextjs docs) so I have a directory structure as follows:
/public/demo/gencenter/gencenter.html which I'm expecting to be visible on
https://cfsnap.com/demo/gencenter/gencenter.html
but I'm getting a 404 (the console reports "failed to load resource.... 404")
Anyone know if a Next.js has any handles I should jiggle to make static files load? For giggles I put a few image files in the /public directory and I can call them directly and they appear as expected:
https://cfsnap.com/demo/gencenter/swimCalendar.png
I read about naming conflicts in the Next.js docs but "gencenter.html" is unique and doesn't exist anywhere else.
Any help would be greatly appreciated.
Rich
Vercel uses clean urls, causing the file "index.html" to be renamed to "index". When I updated my internal links to point to "index" everything started working again. Only applies to html files apparently, CSS and image files remain unaffected.
https://vercel.com/docs/configuration#project/clean-urls
I have a custom font uploaded to the WordPress site. It does not seem to be working on few of the web pages. I was able to identify that the font(source link)for the font on the pages are different. But, i'm not sure how to locate and modify the sources CSS for the website. I'm fairly new to wordpress and this is a Website implemented by a third party.
It would be helpful to know the location on the WordPress where the source can be modified.
Failed to load resource: the server responded with a status of 404 (): CustomFont.ttf
Start with:
Open your website /wp-content/themes/theme_name folder in a good editor like Visual Studio Code, sublime, Notepad++, etc.
Search for the font file name CustomFont.ttf in all files.
That should point you to where it is located.
My website is loading same files with www and without www. I just deleted the file from file manager and its showing 404 which is fine but a different version of it is loading
https://ospreyhomes.ae/wp-content/uploads/2015/01/logo.png (Delete but loading over without www domain)
https://www.ospreyhomes.ae/wp-content/uploads/2015/01/logo.png (Deleted - 404)
How can i get rid of the https://ospreyhomes.ae/wp-content/uploads/2015/01/logo.png being accessed on internet. i have already deleted the file
Same things goes with these 2 files. File deleted but being accessed with url without www
https://ospreyhomes.ae/wp-content/uploads/2015/01/logo.png
https://www.ospreyhomes.ae/wp-content/uploads/2015/01/logo.png
Its almost happen to any file when you have cdn cache service enable like cloudflare. Make sure you clear your browser cache. Try F5. Even not working,Then try a proxy browser to see real-time status of file or disable cloudflare while editing files.
From my side,i see your file has been deleted.
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