Fusion Brain Version 6 -- Beta Testing

Yes, there is only one device connected to the "modem", but not clear what you are referring to: "a switch in there".

If by "global IP" you are referring to the public IP address of the "modem" device (visiable to the public internet), that IP address is passed thru to the Windows 8 box which is successfully running Apache and serving web pages.

Yes, I think we are on the same page when you say "global IP of XXX.XXX.XXX.XXX looks like YYY.YYY.YYY.YYY inside". The Apache server & pingable public IP address 108.XXX>XXX.XXX look like 192.XXX.XXX.XXX inside the local network.

The first problem "Bad Request - Invalid Hostname" when accessing the Window 8 public domain with port ":42422" could indeed be a network setup ("modem" configuration) problem. I won't be there to look for a couple of days.

There is potentially a more severe second problem related to origin policy violation when I attempt to access FuseGL's XML output from a web page served by the Apache server by using XMLHttpRequest(). I'm still testing, but the Windows 8 box is currently not accessible.

With further testing, I have a thought about the failure of the XMLHttpRequest on my local Desktop machine where I double click on the HTML file that contains the XMLHttpRequest: I think it relates origin policy violation caused by the URL on the HTML file being a disk (file:///D:/Documents and Settings/) and the request URL for FuseGL's XML data being "http://localhost:42422".

That doesn't answer the "Bad Request - Invalid Hostname" when accessing the Window 8 public domain with port ":42422" problem, but it eludes to verification of my concern about "origin policy violation when I attempt to access FuseGL's XML output from a web page served by the Apache server" with the additional problem that the Windows 8 Apache server has an URL-IP 108.xxx.xxx.xxx and FuseGL's URL might look like 192.xxx.xxx.xxx.
Even if that takes care of itself depending on access from the public internet or access from the local network, I remain concerned that there will be a violation when the code from the Apache served page attempts to access the XML served by FuseGL.
Wonder if there some aliasing available in the Apache configuration.
Guess I have to wait to get to the Windows 8 machine.

There appears to be a problem with FuseGL unrelated to accessing the Windows 8 machine over the public internet.

On my Desktop test machine I receive the XML data from FuseGL only when I enter "localhost:42422" in the browser directly and never when I enter "192.XXX.XXX.XXX:42422" (the actual IP address on the local network) in the same browser.
When I ping localhost I see an IP address of 127.0.0.1. Entering 127.0.0.1:42422 into the browser is equally unsuccessful at communicating with FuseGL.

This doesn't dispel my concerned that there will be an origin policy violation when the XMLHttpRequest code from the Apache served page attempts to access the XML served by FuseGL, but until I can use IP addresses instead of "localhost", I'm kind of stuck.

Are you able to get FuseGL to respond with XML to a Browser request address other than "http://localhost:42422"?

Quote:

---

Originally Posted by waltersaegir

Are you able to get FuseGL to respond with XML to a Browser request address other than "http://localhost:42422"?

---

On some machines, yes. Others no. I don't know what is going on here, I will look into it. Like I said, it was a quick hack. :)

Ok, I think I figured it out. It requires you to run it with administrator privledges for it to work. It will attempt to listen to everything on that port so the IP:Port and localhost:port will work. But if it cannot get the security privledge to listen to both, it will fall back to only listening to localhost:port.

http://www.image-host.us/user_images..._other_ips.jpg

http://www.image-host.us/user_images...o_machines.jpg

That's good; I tried it on the Desktop machine with the local ip address and it works as Administrator. I'll try across the internet soon. Funny, my login has admin privileges.

I have XMLHttpRequest working to receive FB's XML and I solved the cross-origin policy violation on my Desktop machine. I'm optimistic that it will work across the internet.

Trying to figure out how to use the available methods to parse out things that I need, like "value".

Forever FORWARD!:)

Quote:

---

Originally Posted by waltersaegir

That's good; I tried it on the Desktop machine with the local ip address and it works as Administrator. I'll try across the internet soon. Funny, my login has admin privileges.

I have XMLHttpRequest working to receive FB's XML and I solved the cross-origin policy violation on my Desktop machine. I'm optimistic that it will work across the internet.

Trying to figure out how to use the available methods to parse out things that I need, like "value".

Forever FORWARD!:)

---

I know it will work across the internet as I have also tested it on a VM that proxies back to my house for internet. So from my laptop the connection is going through my cell phone and my house and making the connection between them. So test already achieved. :)

What has started confusing people since Vista is that a user being an Administrator is completely different then running a program with administrative rights. You have to right click and run as Administrator to get the higher security settings even if you are an admin. And if you are just a local user, you can usually still run things as the higher level administrator unless your group policies deny you.

Stopped getting XML data in XMLHttpRequest.Response.XML.xml
Continue to see XML data in XMLHttpRequest.responseText

The web browser is displaying: "This XML file does not appear to have any style information associated with it. The document tree is shown below.".
The XML data "looks" ok, but this is a new message and XMLHttpRequest is having trouble believing that the data is XML now.