TransportParser order restriction (via feature branch) #21
Conversation
…_port,:server_port
transport_parser - added tests to handle different permutations of the above to client_use_spec - disabled logging in client_use_spec.rb as this should only be on for debugging
… release versioned rtsp gems
TransportParser order restriction (via feature branch)
|
Great stuff--thank you! I'll do a little clean up and get this released. You're totally right in that parslet probably isn't the best solution here. I've been working on adding server functionality (in the server-rack branch), in which case I'm planning on ditching parslet and thus getting more aligned with the RFC. |
|
Your welcome, thanks for checking it out. What are you thinking of using instead of parslet? Something close to a JSON parser would be ideal. |
|
I was thinking that I'd end up writing my own parser, as there's probably not anything out there that would fit this need. How do you mean "a JSON parser"? This doesn't seem close to JSON to me… On Jun 25, 2013, at 7:35 PM, nem notifications@github.com wrote:
|
|
I was thinking more on the lines to HCON, like playframework's config parser... http://www.playframework.com/documentation/2.0/Configuration |
|
It's just very flexible and not strict. |
Currently the TransportParser is very restrictive in the order that transport values are parsed. In the RFC spec there appears to be no set order on how client_port,server_port, and source are ordered.
For that matter the entire string except for the very beginning is order independent. Currently in order to get specs passing with a real server "Wowza" I have just per-mutated client_port,server_port, and source.
Wowza helped me discover this issue as their server puts client_port ahead of source. If the URL to the Wowza server is broken, there are plenty of rtsp servers to try from the "RTSP Player" Android App via Channel list.