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

OSCMessage and invalid addresses #67

Open
BryanEnneking opened this issue Jul 16, 2022 · 3 comments
Open

OSCMessage and invalid addresses #67

BryanEnneking opened this issue Jul 16, 2022 · 3 comments

Comments

@BryanEnneking
Copy link

BryanEnneking commented Jul 16, 2022

I believe there is an inconsistency between the spec and the implementation of invalid address checking on messages. In short, the characters '*', ',', '?', '[', ']', '{', '}' should all be allowed in the address. Where these characters are not allowed is in method names (i.e. addresses implemented on the server). An OSC client is allowed to send addresses containing these characters for the purpose of wildcarding and pattern matching. The server then interprets these patterns in order to invoke multiple methods. Therefore, OSCMessage should allow addresses with these characters. Currently, an exception is thrown whenever these characters are in the address. There does not appear to be a way around this. Maybe these characters should be removed from the ILLEGAL_ADDRESS_CHAR regular expression or a constructor could be provided that allows checkAddress to be false.

Here are the relevant links to the spec:
Method Matching
Example

Thanks!

@BryanEnneking
Copy link
Author

Also, I'm happy to make the change if others are in agreement with it.

@dkgof
Copy link

dkgof commented Oct 10, 2022

I agree, those characters should be allowed according to spec.

@hoijui
Copy link
Owner

hoijui commented May 8, 2024

I would accept a PR (sorry, have no time for working on this myself)

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

No branches or pull requests

3 participants