Support CORS (server-side)

[TH3_BUG]

Steam allows us to request Account in XML-format, e.g. http://steamcommunity.com/id/gabelogannewell/?xml=1
This allows us to get the current online and VAC-Status and much more.

But currently it is impossible to request this data on client-side (e.g. via AJAX) because of the Same origin policy, which is why many use Proxies, e.g. via PHP. This is unnecessary these days und just overhead.

Modern browsers support Cross-Origin Resource Sharing. Steam needs to add just one HTTP-Header to enable CORS.
https://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/

[root]

Take a look at an earlier thread involving this same topic. http://forums.steampowered.com/forum...3#post30322343

Do you still feel adding CORS support is a more viable solution than working around the issue?

[TH3_BUG]

Originally Posted by root

more viable solution than working around the issue

You just answered your own question.

From my point of view proxying isn't even a solution. It just moves the issue and adds even more unnecessary server load and delay to the requests.

[root]

But that load and delay is usually unnoticeably small. Either you get the information directly and we consider the time required to be the delay between when your program requests the info and it gets a response, or you get the information through another local means and we consider the time required to be the delay between when the proxy program requests the info and it gets a response plus the time it takes for the proxy program to relay that to the original program. The difference between the two scenarios is a matter of miliseconds, dont you think?

Unless there is more complicating the second case than has been made evident, I would suggest you take that extra-milisecond hit.

[TH3_BUG]

Originally Posted by root

But that load and delay is usually unnoticeably small.

Nope. I did happen more than once, that steam servers were damn slow. Also it would completely remove the benefit of geolocated server since i can't control which server handles my request. I guess it's a server somewhere at the border of the world.

Originally Posted by root

the difference between the two scenarios is a matter of miliseconds, dont you think?

See above. In best-case it doubles the server response time and halves the requests the server can handle per second.
I really don't want to run an extra Server to proxy requests to the steam community.
For small clan-pages or whatever a proxy-"solution" (no it isn't) may be OK but for bigger websites this is not an option.

Whats the problem of adding one Response Header

[root]

Originally Posted by TH3_BUG

Nope. I did happen more than once, that steam servers were damn slow. Also it would completely remove the benefit of geolocated server since i can't control which server handles my request. I guess it's a server somewhere at the border of the world.

I dont understand what you mean to say here. Geolocation has little to do with how much processing time it takes to have two local programs interacting with eachother.

Originally Posted by TH3_BUG

See above. In best-case it doubles the server response time and halves the requests the server can handle per second.
I really don't want to run an extra Server to proxy requests to the steam community.
For small clan-pages or whatever a proxy-"solution" (no it isn't) may be OK but for bigger websites this is not an option.

From this, I believe a miscommunication has occured. A distinction should be made between a proxy connection (tunneling traffic to another computer entirely) and the generic sense of a proxy (something acting in place of something else). Depending on your hosting provider, you can very well have one server/computer running a PHP script to deal with the communications with the Steam servers, and then have the same server/computer running your actual program alongside it, using the PHP script to sidestep the communication issues.

Originally Posted by TH3_BUG

Whats the problem of adding one Response Header

I will admit that it's hackish to take the approach I've proposed, but realistically, you arent likely to see Valve add anything in the way of what you're asking, at least not soon enough to matter. And in my opinion, that's rightfully so, since adding more layers almost always adds more problems. Security vulnerabilities and privacy issues have the potential to manifest with the addition of CORS support. It's a lot more complicated than just tacking a few extra words onto outgoing data.

[TH3_BUG]

Originally Posted by root

I dont understand what you mean to say here. Geolocation has little to do with how much processing time it takes to have two local programs interacting with eachother.

Why two local programs? Client at place A, request gets served by the nearest server (=> Geolocation) at place B which has to make a request to a Steam Server at place Z.

halves the requests the server can handle per second

extra Server to proxy requests to the steam community

Got it?

Originally Posted by root

that's rightfully so, since adding more layers almost always adds more problems.

A Proxy isn't an additional layer?

Adding one more header is just 1 line of code.

[root]

Originally Posted by TH3_BUG

Got it?

Sorry, but not really. Are you trying to say your application will be serving to many clients from many different servers you operate? I was under the impression this was a humble project that wouldnt see more than 100-200 clients at a time, which is totally possible from a single server you operate, running the single application and communication backend program, talking to the server from Valve. In such a case, you need no more than one server, operating two processes locally, to itself.

Originally Posted by TH3_BUG

Adding one more header is just 1 line of code.

It isnt, though. You are asking Valve to consider which of their resources should be exposed to external scripting. They would have to consider how much privacy the exposed resource could breach, as well as the security implications of allowing potentially malicious scripts to operate on these resources. It requires a lot more planning than just dropping a line into an Apache config and walking away.

[TH3_BUG]

Originally Posted by root

It isnt, though. You are asking Valve to consider which of their resources should be exposed to external scripting.

Well in old browsers it already worked since they didn't know the same origin policy. In some newer (but not modern) browsers there are some hackish solutions via iframes.
For production use this is not an option today, since modern browsers deny the request without CORS. But you could still use proxies, as mentioned more than enough times.
In fact there is not a single new resource which would be exposed.

Originally Posted by root

as well as the security implications of allowing potentially malicious scripts to operate on these resources

they could read them, nothing more and nothing less. Already possible.

Originally Posted by root

from many different servers

That was meant as an example for the doubled load

Proxying is still no solution!
And no, there is no need for further discussion.

[root]

Originally Posted by TH3_BUG

And no, there is no need for further discussion.

Have it your way then. Sorry I couldnt be of more help.