I have a manifest that looks somethin like this:
CACHE MANIFEST
# e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a
/a/application.js
/a/application.css
NETWORK:
*
FALLBACK:
/ /offline/redirect
The issue is that my /404.html and /500.html pages (that are obviously served up with a response code of 404 and 500) are triggering the fallback. They both act just as if the server is offline.
My question is twofold:
Why does /404.html trigger the fallback when /events doesn't?
How can I allow /404.html and /500.html to not trigger the fallback while still allowing / to
trigger it.
For what it's worth, I've already tried this:
NETWORK:
*
/404.html
/500.html
... however since those pages are served w/ a non-200 response code, it triggers the app cache error callback and the cache isn't saved.
Thanks!
What worked for me:
Remove * from the NETWORK declaration
Redirect to /404.html (et al) instead of rendering in place.
So using the example above: /teams/1241231 302 redirect to /404.html which returns a 404 status code.
Related
Our Apache server is getting 404 errors when we get a GET request for a "no longer valid" css file. The html pages that use the css all have "cache-control: no-store, no-cache, must-revalidate" set. HTTP_REFERER is always empty for these 404 calls.
The IP addresses of many of the 404 prefetch calls eventually result in a sale on the same IP address, which leads me to believe this is **not **the new Chrome prefetch (https://developer.chrome.com/blog/private-prefetch-proxy/), since the Chrome prefetch hides the users IP.
We are working around this problem by 301ing to our new css just in case this is causing end users to see un-styled pages, but I'm curious about what is causing the problem. Any ideas?
Thanks,
Ed
We tried 301ing to our new css. We expected that an old css file would not be fetched.
Up until several weeks ago I was able to stream icecast and shoutcast on my HTTPS site. This would create a "mixed content" warning but was never explicitly blocked.
Now I find that chrome is forcing the http://streaminglink urls to load https://streaminglink and I can't access the http audio anymore.
Here is a code example in jPlayer
$("#jquery_jplayer").jPlayer("setMedia", {
mp3:"http://149.202.79.68:8213/stream.mp3"
});
I expect chrome to load the http url but instead it is looking for the https and I get the following error in the console:
GET https://149.202.79.68:8213/stream.mp3 net::ERR_CONNECTION_CLOSED
NOTE
The https ^ - that's not coming from my code or configuration... =/
So it looks like this is default behavior for Chrome since 79.
https://www.engadget.com/2019/10/04/chrome-security-block-http-content/
Broke my site. Thanks Google.
you can now allow insecure content in the specific site settings
chrome://settings/content/siteDetails?site=https%3A%2F%2F<SITE_DOMAIN>
We have a website and our domain is on dnsimple and server is on heroku. We configured all necessary steps with ssl both on heroku & dnsimple.
When you type any of these 4 urls to url bar it works.
But the problem is, when I search on google as my website and click on the link, it is not opening especially with internet explorer & safari. It gives 404 error.
Error from the console;
ActionController::RoutingError (No route matches "https://www.google.com.tr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwiU0JX39YnQAhWJEiwKHSq2BpQQFggcMAA&url=https%3A%2F%2Fwww.example.com%2F&usg=AFQjCNFg0D1KFk0WGvYOfUoVzNm19KDBYw&bvm=bv.137132246,d.bGg"):
I have added all 4 websites to google search console as;
https://www.example.com
https://example.com
http://www.example.com
http://example.com
Its been more than 24 hours btw. For internet explorer I tried to remove history and flush dns config. Still no luck.
EDIT:
There is no checks as referrer. But there is a code to show header or not as in application controller but I do not think this is relevant;
before_filter :set_locale, :location_action_name
def location_action_name
if !logged_in?
url = Rails.application.routes.recognize_path(request.referrer)
#last_controller = url[:controller]
#last_action = url[:action]
end
end
EDIT2:
I removed the below code and pushed to heroku now it works. But why is that?
The issue is caused by the following code fragment:
url = Rails.application.routes.recognize_path(request.referrer)
#last_controller = url[:controller]
#last_action = url[:action]
As far as I remember (and I guess, given that recognize_path was removed in recent versions of Rails) recognize_path raises a routing error in case it can't find the path.
You are passing arbitrary strings to the function, but the function only recognizes paths internally described in the router.
request.referrer would return 3 different types of URL:
blank: when no referrer
external URL: when the visitor clicks elsewhere and reaches your app
internal URL: when the visitor clicks somewhere in your app
In all cases except the third one, recognize_path will raise an error. The error will be caught by the default Rails handler and displayed as 404 (an unrecognized route results in a 404 in production).
I'm not sure what location_action_name is supposed to do, but as it is implemented now it's very fragile and in most cases it will result into causing 404 responses in your app.
I've been working on an Spring MVC application that has custom error pages, these pages return a generic error message and the stack trace as an HTML comment. I'm currently developing the offline funcitonalities of this application using HTML5's Appcache. My manifest is something like this:
CACHE MANIFEST
CACHE:
... my explicit entries (not relevant) ...
FALLBACK:
... some fallback entries (not relevant) ...
<!-- This next line is relevant --!>
/ pageNotFoundOffline.html
SETTINGS:
prefer-online
Which is supposed to serve a previously cached 404 page when the user can't connect to the server, the problem is that it also serves this 404 page when an error occurs, thus rendering completely useless the custom error page already implemented in the application.
Why i want to do this? i want that whenever a user tries to access any page on my application and the request fails with a 404 (either because the is no available internet connection or because the servers are down), that user is informed that the request failed and he or she is being redirected to our offline functionalities, also i want to inform the user when he or she succesfully reached our servers but an internal error occurred (through the custom error page).
Is there a workaroud for this problem?, what i would like to accomplish is the cached 404 page to be served only when there is a 404 exception and the custom error page returned by the server to be displayed when there was an internal error.
I'm afraid that it is not possible with appcache - the fallback intercepts all server errors. The specification for appcache says: "If this results in a redirect to a resource with another origin (indicative of a captive portal), or a 4xx or 5xx status code or equivalent, or if there were network errors (but not if the user canceled the download), then instead get, from the cache, the resource of the fallback entry corresponding to the fallback namespace f. Abort these steps."
If you can use the more modern way of doing things, Service Workers, I would recommend using that, as that will let you do what you want.
I'm using the application cache to make my website also work offline.
My manifest looks something like this and is embedded using an <iframe>:
CACHE:
favicon.ico
assets/css/style.css
assets/js/libs/zepto.js
assets/js/app.js
NETWORK:
*
FALLBACK:
/ offline.html
it works as expected when I cut the internet connection -> everything is served via the offline.html page.
but just now I found out that every 404 (e.g. an URL that never existed on the server) also uses the FALLBACK section in the manifest on displays the offline.html.
is there a way to distinguish between being offline (in which case the offline.html is the right choice) and the server returning a 404 (in which case I just want to display the 404 error)?
Appcache will FALLBACK if the original request...
...results in a redirect to a resource with another origin (indicative of a captive portal), or a 4xx or 5xx status code or equivalent, or if there were network errors
(from http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel)
Unfortunately, when a fallback occurs, there's no why to find out why. You can't differentiate between a 500, 404, redirect or failed connection.
Here's a hacky workaround:
FALLBACK:
/connection-test.js connection-failed.js
/ offline.html
You could embed connection-test.js in your offline.html page. connection-test.js loading would indicate the user has a connection, connection-failed.js would indicate there's no connection.
I came across your post while searching for a solution to this same problem.
What I ended up doing was checking the value of navigator.onLine in my fallback page (which, in your case, would be offline.html). If navigator.onLine is true, then the user is supposedly online/connected to the internet (caveats apply), and were sent to the fallback page because the file they requested was not found. So, then I change the content of the page to that of a 404.
Example:
<script>
header=document.getElementById('header');
error_message=document.getElementById('error_message');
if(navigator.onLine){
header.innerHTML='Page not found';
error_message.innerHTML='The page you requested could not be found. Please check the URL and try again.';
}
</script>
It would certainly be great if the application cache spec included some other way of handling 40x's and 50x's. While this solution is certainly not ideal, it's the best one I could come up with.
I hope it helps.