Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for inline (same port) flash socket policy request #85

Merged
1 commit merged into from
Oct 29, 2010

Conversation

kanaka
Copy link

@kanaka kanaka commented Oct 24, 2010

Requiring that the server be run as root is generally considered a bad idea. This change listens on the target port for flash policy requests if the listener can't be started on port 843 (i.e. not root priveleged) and so it allows the flashsocket mode to work without root privelege.

I also suggest reversing the warning so that running as root produces a warning instead. Or perhaps having a (different) warning for both.

If the server is not run with root privileges, then the flashsocket
transport will instead listen to all new connections on the main port
for policy requests.

Flash policy requests happen to both port 843 and
the destination port:
http://www.lightsphere.com/dev/articles/flash_socket_policy.html
@rauchg
Copy link
Contributor

rauchg commented Oct 24, 2010

Good stuff! Will merge asap

@3rd-Eden
Copy link
Contributor

I would say remove the if (netserver == null) { statement so the line flash socket policy can be used as backup for when for some reason the netServer fails to respond to a client.

@kanaka
Copy link
Author

kanaka commented Oct 27, 2010

Hehe. I added that so that it would be a more palatable pull request since with the check it doesn't affect the current default behavior. I'm all for removing it.

darrachequesne added a commit that referenced this pull request Jul 4, 2024
ArrayBuffer.isView method is not defined in IE10.
darrachequesne added a commit that referenced this pull request Jul 8, 2024
This reverts commit 44c7aa5, which caused string payloads to be encoded
as binary (so that huge string payloads were needlessly UTF-8-encoded).

Related: #2872
darrachequesne added a commit that referenced this pull request Jul 8, 2024
That will allow clients receiving the xhr payload with
responseType = 'arraybuffer' to properly decode the message, which is
not sent as binary by the backend anymore since 292c00c (#85).
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants