Recursive loop in admin on unicode domain name

Gumster

I'm setting up Fuel on a new server, and when I use the admin with Firefox, links like:

/fuel/dashboard
/fuel/manage/cache

work OK, but others,

/fuel/pages
/fuel/sitevariables
/fuel/blocks

go into a recursive loop whereby the right hand column repeats the parent frame, so that (briefly) the entire admin fuel/blocks view appears inside where the fuel/blocks list page would be. Example screenshot

In a local environment on a Mac, there isn't any problem, so what else might be wrong - I've never seen this behaviour before? The default htaccess won't work on the server (I have to remove Options +FollowSymLinks or the pages 500) but this isn't an issue for the local copy, and in any case I can't see any relation to symlinks.

Gumster

At first I thought that overnight the issue had fixed itself - but I had viewed the site in Firefox yesterday, and in Chrome today.

Basically, some of the site admin goes into a redirect loop using Firefox or IE, but is OK in Chrome and Safari.

The site has a unicode domain (it has an umlaut in the domain name). Could this be an issue?

Gumster

The local dev site behaves OK in Firefox, so I am wondering if it is a unicode problem. The site in question is actually an SVN code branch of a site with a regular English domain name (which works perfectly), but the new branch only misbehaves when on the German, umlauted, domain (incidentally, Chrome redirects to the xn-- IDN domain version, so perhaps avoids the issue by doing that)

PHP is v5.6.7 on the German domain.

A consistent error in the browser console, before the redirect loop makes debugging impossible, is with jqx.createController(). Maybe this is just one of the last things to get logged.

admin

That is strange and have never seen that before. Sometimes throwing an alert right after the JS error will pause the execution so you can look at the error before it redirects. You can try adding one to the jqx.js file.

Gumster

In the console I can occasionally see the urlencoded umlaut domain (which is of course bogus) but not what is calling it

Gumster

Firefox Web Developer Edition console reports:

TypeError: jqx.createController is not a function 

when loading the pages module in admin. PageController.js is the last thing recorded on load.

I can't see jqx.js being loaded on the Pages module, whereas it is loaded with fuel.min.js and jquery, with timestamp parameters by the dashboard first thing - that would explain the "not a function" log.

There's a play/pause in FFWDE's debugger console which has a similar effect to the alert option you suggested.

admin

The jqx file should be loaded near the footer in the HTML and initialized right after that. Do you see that in the HTML?

Gumster

I was trying to see when or if it got executed in the console. It may be irrelevant. What I'm trying to figure out is how the right hand list area is getting the entire parent page injected? All that should happen is an ajax call to the module controller items method, which should produce an HTML table response - but is instead fetching the entire /fuel/blocks url (in the example screenshot). What would make the ajax call do that, and how is it related to (if it is) unicode? The gears are still grinding on that one!

admin

This may be a rabbit hole, but we ran into a really strange issue that reminded me of this issue a while back on a MediaTemple Grid server where it wasn't properly creating the AJAX headers and so in the module controller, the is_ajax() function wouldn't return correctly. It was sporadic in that it would work the first time, and then subsequent calls would not send that header. This actually wound up being an issue with MediaTemple that they were going to look into (has something to do with their version of FastCGI). The test we did was to print out the $_SERVER variable for an ajax request to see if it returned the [HTTP_X_REQUESTED_WITH] => XMLHttpRequest.

Gumster

I have a nuke option, which is to use the non-unicode domain when accessing the admin, but if I find a solution otherwise, I'll let you know.

Gumster

I've managed to capture the response of this url in the pages module:

/fuel/blocks/items/?search_term=&limit=50&view_type=list&offset=0&order=asc&col=name&fuel_inline=0

and it returns the entire /fuel/pages DOM, instead of just:
<div class="nodata">No data to display.</div> <input type="hidden" name="offset" id="offset" value="0" /><input type="hidden" name="order" id="order" value="asc" /><input type="hidden" name="col" id="col" value="location" />

So that does suggest the problem you mention - its as if the module controller items() method isn't recognising the request as ajax, so delivers a full list page?

And... looking deeper..., thanks for mentioning it, the X-Requested-With:XMLHttpRequest header isn't visible in Firefox, but is in Chrome. Printing out the $_SERVER['HTTP_X_REQUESTED_WITH'] does result in NULL.

So the unicode problem I thought it might be seems less likely.

Elsewhere on the server I wrote a simple ajax call, and that responds OK - the HTTP_X_REQUESTED_WITH is present and correct even in Firefox, so there seems to be just an issue with the admin, and admin pages with module ajax calls.

admin

If I remember correctly, I think we figured it had something to do at the server level and that it seemed to be caching the requests. When you go to that page, it actually first does the normal non-AJAX request to that page which returns the entire contents of the page, and then it does the AJAX request to that page to render to the table. So the first time it hits that page it is the non-AJAX page, then that page makes a subsequent AJAX request to itself which returns the table view. So that page behaves differently depending on if it is AJAX or not. The behavior we observed seemed to be looking at a cache and just returning the page that was initially stored at that URL (the non-AJAX).

Gumster

I understand what you're saying, but why only Firefox or IE? Also, in Firefox, the initial load of the pages module is always wrong - I've just emptied the browser cache to prove that.

I take it then that the $_SERVER['HTTP_X_REQUESTED_WITH'] index is absent because the page is recognised as cached? So, an ajax call that refused a cache might be worth a try.

I'm not clear what is calling the ajax request - is it PageController.js?

admin

BaseFuelController.js redrawTable method

Gumster

I haven't made any headway with this issue - fortunately, the application can be accessed using a non-unicode alternative domain, and the Fuel admin works as expected.

It seems that unicode - or punycode - is the norm, and that browsers will show the IDNA as intended, but really operate on plain ASCII.

And yet something Ajaxy breaks on the IDNA version but not otherwise.

This link gives an overview of the situation for Switzerland (3 national languages)

admin

Interesting... and thanks for posting back.