API inconsistencies with webrtc example

[bengreenier]

These results come from manually diff-ing behavior between webrtc peerconnection_server and us

• Always specifies Connection header close
• Always specifies Cache-Control header no-cache
• CORS exposes header X-Peer-Id, but it seems the client example doesn't use it and the server doesn't parse it.
• Uses HTTP/1.0.
• Server header is set to PeerConnectionTestServer/0.1

GET /sign_in

query is optional, if given there is no key (so it's just ?name)

There is some GC of connections done by the notifier, when iterating through peers to tell them status has changed.

GET /sign_out

any error (like non existent peer) results in a 500

POST /message

Content-Type is maintained/matched

[bengreenier]

https://github.com/bengreenier/webrtc-signal-http/commit/b478c81fb225e7a09af1908918980625370505c6 addresses some of these (on npm as 2.0.0-alpha.1, tag alpha). Remaining issues:

GET /sign_in

query is optional, if given there is no key (so it's just ?name)

There is some GC of connections done by the notifier, when iterating through peers to tell them status has changed.

GET /sign_out

any error (like non existent peer) results in a 500

[bengreenier]

i'm planning to solve this with Accept: application/vnd.webrtc-signal.2 for api versioning. The default version is 1. version 1 behaves exactly like the webrtc example. version 2 adds these (arguably logical) changes:

• requires peer_name=<customName> query format, specifying a name is required
• more detailed error statuses (404, 400, 500) will be used when applicable

[bengreenier]

as proposed https://github.com/bengreenier/webrtc-signal-http/commit/229cc8ca790a11acc9cb26f00b402987bcad8884