I am getting an endless loop with a concrete5 site that just went live today... it was fine in development using a temporary URL, but now live only the homepage works... was wondering if this has something to do with pretty URLS.
error: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
Site is http://redletterdaysforbusiness.co.uk
It seemed all was okay with the rewrite rules, and the error was in fact within C5 itself...
When developing the test site I had enabled pretty URLS, once I went live and changed the URL this didn't work anymore.
By disabling pretty URLS, all links worked. Then re-enabling prety URLS, everything still working.
Thanks jcem for you input.
Related
This is a weird problem and I apologize beforehand that I may not give enough details:
We have a pretty standard Angular app that needs to access an API on a different (sub-)domain, using CORS. Everything works perfectly fine on Chrome and Firefox. We also got it working on IE >=9.
Unfortunately, some of our customers need to access our public website from within their company intranet. In this case, using IE, only a couple API requests go through. Chrome and Firefox cause no problems.
They can create a sessionThey get the result of a second GET requestBut the third request fails
In the console, we see an Access Denied message caused by a GET request.
**AND**: When they reload the page, the third request goes through. One customer could bypass his intranet and access our website directly. Then, everything worked like a charm.
Please note that we are only aware of issues with IE 11.
Any help is really appreciated.
I have a VM that I set up to do development on two sites hosted on Acquia with the same codebase. I'm using version Drupal 7.26. I have it where I can access both sites from the host computer, but when I try to log in using /user/login on either site, I get nothing. The POST returns a 404 containing the log in page again.
I've tried settings $cookie_domain = '.my-site.dev' as well as $cookie = 'www.mysite.dev'. Neither has any effect. I also tried adding a bunch of random charactersto the file to make sure I was editing the correct file; with the random characters, pages didn't load at all. (See https://www.drupal.org/node/611920#comment-3110010.)
I also tried doing repair table sessions. I forgot which site I saw that recommendation from. I also tried delete from sessions just for kicks. Neither worked.
Any ideas? Thanks!
edit: Per https://www.drupal.org/node/261411#comment-3182566, I tried to go to www.mysite.dev/?q=user/login. This did not give me a 404, but I had tried (unsuccessfully, it seems) to reset my password through the database. I'm at least getting an error about a bad username/password combination rather than nothing at all. Still, I would think /user/login should have worked, too.
edit 2: The production site uses CAS, but logging in through /user/login still works.
(yes - cross-posted from the google-appengine google group...I can't tell if they answer support questions like this there or here or what...it's all kind of a mess :) )
I am having a problem logging in to the appengine console using certain accounts on my google apps domain (but not others).
No matter what browser I use (Firefox, Chrome, Safari, IE), I get a "too many redirects" error on https://appengine.google.com/start when I try to log in using a specific account. I have tried resetting all the browsers as well (clearing all cookies, cache, etc - even trying it on a clean install of an OS) - with no luck. Going directly to https://appengine.google.com/a/domain.name causes the same loop for those accounts. The same thing happens when running the browsers with privacy mode enabled.
One of the accounts having problems is the user nathan.toone on the k9webprotection.com google apps domain - however we can log in with the user "admin" or the user "build-agent" on the same domain just fine (but not "build.agent" or "user2"). It seems to be all over the place as to which accounts are able to log in without the redirect loop and which ones aren't.
I have contacted google apps for your domain support, and they have said that it is outside their scope. They very "helpfully" pointed me to https://developers.google.com/appengine/kb/general - which didn't help AT ALL. :(
Again - the odd thing is that there are some of the accounts on the same domain that are able to log in just fine. Does anyone have any idea what could be happening, or have a way for me to contact someone to get this worked out? I have found a couple of other people saying they have had this problem, but have not been able to encounter a solution.
-Nathan
I have a fairly big application which went over a major overhaul.
The newer version uses lot of JSONP calls and I notice 500 server errors. Nothing is logged in the logs section to determine the error cause. It happens on JS, png and even jersey (servlets) too.
Searching SO and groups suggested that these errors are common during deployment. But it happens even after hours after deployment.
BTW, the application has become slightly bigger and it even causes deadline exception while starting few instances in few rare cases. Sometimes, it starts & serves within 6-10secs. Sometimes it goes to more than 75secs thereby causing a timeout for the similar request. I see the same behavior for warmup requests too. Nothing custom is loaded during app warmup.
I feel like you should be seeing the errors in your logs. Are you exceeding quotas or having deadline errors? Perhaps you have an error in your error handler like your file cannot be found, or the path to the error handler overlaps with another static file route?
To troubleshoot, I would implement custom error pages so you could determine the actual error code. I'm assuming Python since you never specified what language you are using. Add the following to your app.yaml and create static html pages that will give the recipient some idea of what's going on and then report back with your findings:
error_handlers:
- file: default_error.html
- error_code: over_quota
file: over_quota.html
- error_code: dos_api_denial
file: dos_api_denial.html
- error_code: timeout
file: timeout.html
If you already have custom error handlers, can you provide some of your app.yaml so we can help you?
Some 500s are not logged in your application logs. They are failures at the front-end of GAE. If, for some reason, you have a spike in requests and new instances of your application cannot be started fast enough to serve those requests, your client may see 500s even though those 500s do not appear in your application's logs. GAE team is working to provide visibility into those front-end logs.
I just saw this myself... I was researching some logs of visitors who only loaded half of the graphics files on a page. I tried clicking on the same link on a blog that they did to get to our site. In my case, I saw a 500 error in the chrome browser developer console for a js file. Yet when I looked at the GAE logs it said it served the file correctly with a 200 status. That js file loads other images which were not. In my case, it was an https request.
It is really important for us to know our customer experience (obviously). I wanted to let you know that this problem is still occurring. Just having it show up in the logs would be great, even attach a warm-up error to it or something so we know it is an unavoidable artefact of a complex server system (totally understandable). I just need to know if I should be adding instances or something else. This error did not wait for 60 seconds, maybe 5 to 10 seconds. It is like the round trip for SSL handshaking failed in the middle but the logs showed it as success.
So can I increase any timeout for the handshake or is that done on the browser side?
I get this warning often in my Google App Engine for Java warning console. It's strange because the URL that it claims isnt handled, is the url generated by GWT (im using GWT client-side).
Heres an example: /myAppName/62865E45F313D707543A6F093D199127.cache.html
They only happen occasionally, but its enough to make a single visit useless.
I'm not 100% sure, but it could have to do with browser cacheing (though the *.ClientMod.nocache.js is specifically designed to prevent this). Does clearing your browser's cache or visiting the page in incognito mode help?