Accept / content type header for the win IMHO.
On Mon, Jan 6, 2025, 06:51 Juliusz Chroboczek <jch@irif.fr> wrote:
> Nils Ohlmeier:
>
> > - mandate that the URL needs to have a certain "file" ending like other
> > existing media URLs; probably also not a great solution
>
> Please no. In HTTP, the URL namespace is for the application to use as it
> wishes, that's why we have things like Content-Type and Accept.
>
> Concretely, if I want to put my WHEP endpoint at
>
> https://galene.example.org/accounts.xls
>
> then I'll put it at accounts.xls, and no standardisation body has any
> right to tell me otherwise.
>
> Ben Schwartz:
>
> > This looks like a case for HTTP Content-Type negotiation. For example, a
> > video client that supports DASH, HLS, WHEP, and raw WebM could send a
> request
> > header like
> >
> > Accept: audio/mpegurl, application/vnd.apple.mpegurl,
> application/dash+xml,
> > application/example-whep, video/webm
> >
> > and the response could choose one in the Content-Type header.
>
> That was also my first reaction. However, that would imply the need to
> allow GET or at least HEAD to a WHEP endpoint. Consider the application
> that doesn't know the protocol: in order to start protocol negotiation, it
> will either GET or HEAD the endpoint. What will the WHEP endpoint reply
> with?
>
> -- Juliusz
>
>
> --
> Wish mailing list -- wish@ietf.org
> To unsubscribe send an email to wish-leave@ietf.org
>