It would be very useful if the pubstats script on LFSWorld would add the HTTP Access Control header to allow for greater creativity, and propagation of the data stored there via the Cross-Origin Resource Sharing recommendation.

All that must be done is, add the following header into the pub stats script.

This will then allow the use of AJAX directly without having to use a file on the server to request the information for the client, as enforced by the same-origin policy thus reducing resources on the serving web servers end, and allowing for a more robust experience overall for the client.

Also, defaulting the output should depend on the information obtained. If &s is not set, then use this information for clues:

If the user_agent is not set, then it's probably a call from PHP as it has no default user_agent, and the output should be the sterilized string.

If the $_SERVER['HTTP_ORIGIN'] is set, then the output should be XML.

All else should be plain text unless otherwise specified.

The use of HTTP status codes would also be a nice touch.

When the &action is undefined within the script

When the IDK is invalid or Username & Password is invalid return:

• 530 User access denied

When the client is using Premium Stats and They have Run out of Money

When the pubstats script receives a POST header, and not a GET.

When the &version number is less then the current version.

A client has gone over their bandwidth limit (Again Preminum Stats)

Quote from Dygear :

It would be very useful if the pubstats script on LFSWorld would add the HTTP Access Control header to allow for greater creativity, and propagation of the data stored there via the Cross-Origin Resource Sharing recommendation.

I do recommend that you read into the standard, as it does allow for some interesting possibilities. You could have the client lock down their pubstats access by domain name also, where they know requests will only come from 'domain.example' then they can enter this details into their account. But for this also, you should set an expires date on the origan control to make sure that when the client removes the domain from their list, that it is accepted by the client's user agent and checked again at a later date to ensure conformity.