wish-wg / webrtc-http-ingest-protocol

WHIP - WebRTC HTTP ingest protocol draft
47 stars 10 forks source link

Identify WHEP endpoint using response from OPTIONS request #88

Closed birme closed 1 year ago

birme commented 1 year ago

For a client to be able to determine that a URL is a WHEP Endpoint resource I propose that the response of an OPTIONS request must have an accept-header including the application/sdp content-type. For example:

curl -v -X OPTIONS http://localhost:8300/whep/channel/test
> OPTIONS /whep/channel/test HTTP/1.1
> Host: localhost:8300
> User-Agent: curl/7.79.1
> Accept: */*

< HTTP/1.1 204 No Content
< vary: Origin, Access-Control-Request-Headers
< access-control-allow-origin: *
< access-control-expose-headers: Location, Accept, Allow
< access-control-allow-methods: POST, GET, OPTIONS, PATCH, PUT
< accept: application/sdp
< Date: Mon, 03 Oct 2022 11:56:48 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 

This way a client can query the URL and understand whether it is a WHEP URL or something else. A use case is when you have a player library that can play both HLS/MPEG-DASH and now also WHEP.

murillo128 commented 1 year ago

The idea is to return an Accept-POST header instead in the 200 OPTIONS request

OPTIONS /whep/channel/test HTTP/1.1 Host: localhost:8300 User-Agent: curl/7.79.1 Accept: /

< HTTP/1.1 204 No Content < vary: Origin, Access-Control-Request-Headers < access-control-allow-origin: * < access-control-expose-headers: Location, Accept, Allow < access-control-allow-methods: POST, GET, OPTIONS, PATCH, PUT < accept-post: application/sdp < Date: Mon, 03 Oct 2022 11:56:48 GMT < Connection: keep-alive < Keep-Alive: timeout=5

murillo128 commented 1 year ago

done