[vlc-devel] Factor HTTP/HTTPS/RTSP port in core

[Rémi Denis-Courmont]

   Hello,

On Friday 16 September 2011, Pierre Ynard wrote:
> > That won't work for dual-stack.
> 
> Sure, the code needs to be adapted a bit to make it work.

I don't believe you can get a correct purely boolean answer to the "Is this 
the same HTTP host" question? What if one host is unspecified, and another one 
is "0.0.0.0" ? What if one host is "localhost" and another one is "::1"? They 
_partially_ overlap. Too complicated to implement, and practically impossible 
to understand except for you and me.

> > Even if we ignore this, it would be confusing in any case.
> 
> No, I disagree. I don't understand why you keep throwing around the word
> "confusing" without facts.

HTTP host names are typically used for for virtual hosting (the HTTP Host 
field), not for DNS resolution. Frankly, I'd rather we just bind VLC to both :: 
and 0.0.0.0 always.

Binding to a specific address is tiny corner use case. I do not see a problem 
with requiring two separate VLC processes to bind VLC to different (non-
default) IP addresses. You can probably count the number of world-wide users 
with your fingers.

> > The current approach on the other hand, is quite clear, though
> > different from earlier.
> 
> Don't be a GNOME simplicity nazi; of course it's clear, because it's
> *dumbed down*

You've been following the IRC channel and you might have followed the web 
forum. HTTP streaming output is confusing. Any step toward simplification, that 
does not remove meaningful use cases is a good thing.

We can debate GNOME nazism the day VLC gets under one hundred command line 
switches...

> > And it still fails to address TLS certificate issues.
> 
> For the 4th time, what are the TLS issues? Anyway, the TLS and server
> address issues are not really bound together.

How do you configure the certificates? Currently, VLC can only use one 
certificate and key per HTTPd host. So per-chain / per-interface configuration 
did not work correctly.

Just like the bindind address, I think limitting VLC to one key pair per 
process/instance is good enough, and it eliminates the design bug.

> > >    * decide whether we want unspecified/zero port values that can mean
> > >    
> > >      an OS-assigned port instead of being replaced by the default
> > 
> > This is meant to be used for ephemeral ports, which those are not.
> > I don't know any software that would allocate an ephemeral port by
> > default, except where some kind of rendez-vous mechanism negotiates it
> > (e.g. UPnP, FTP data, RTSP RTP/RTCP pair).
> 
> Okay, but I didn't mean it should be the default; just a feature
> that could be used when you need it. A use-case mentioned earlier is
> automated tests of server functionality.

You can set the port to zero if you really want to. It might even make some 
sense if/when the HTTP interface gets Bonjour support (or any other rendez-
vous mechanism / discovery protocol).

It should work though I have not tested it. Still a non-zero default port is a 
lot clearer as far as preferences are concerned. I am not a huge fan of magic 
values (0, -1 or whatever) in the preferences, though they are sometimes 
unavoidable with the limitations of the subsystem.

> > >    * choose between URI, the de facto standard "<host>:<port>"
> > >    
> > >      representation, separate host and port parameters, something
> > >      else, or a combination thereof
> > 
> > This is NOT a de facto standard for on the server/listening side. In
> > fact, Apache separates the per host path "<Location /foo>" from the
> > host name "<VirtualHost IP:port>".
> 
> So Apache uses the "host:port" representation too? Yes, that's exactly
> my point. Right, that doesn't include the path, it would be separated in
> another parameter.

"host:post" as OPPOSED to "http://host:post/path".

> > >  - convert to this consistent syntax all these parameters throughout
> > >  
> > >    the vlc code base, without breaking compatibility, adding new
> > >    parameters where needed
> > 
> > Consistent across access output destinations?
> 
> No, across the code base. Including access outputs yes, --sout which
> also accepts an MRL in place of a sout block, the rtp sout and its sdp
> parameter, VoD which still uses the path component of --rtsp-host,
> the rc interface which expects <host>:<port>, telnet which accepts
> <host>:<port> *and* a separate --telnet-port, the lua CLI which now
> takes a telnet URL, DVB HTTP whose configuration is gone, and other
> stuff given by grepping the help: --rmtosd-{host,port}, --sout-raop-host

RAOP is a push protocol. DVB HTTP was a hack and is not working at all 
anymore.

It's not my fault if VoD and telnet are ill-designed too. Feel free to fix them 
to two separate configuration options. Most daemons split those two things, 
including Apache with its Port and Bind directives.

> > HTTP is now (mostly) consistent with file. FTP upload is kinda
> > "special". UDP is legacy crap and is special too.
> 
> There are no central --file-host and --file-port options.

HTTP is consistent with file as far as both of them now expect a file path 
relative to the host (implicitly the local file system for file).
 
> No, this doesn't set defaults, implying they can be overriden. This sets
> the one and unique value to be used everywhere.

They could be overriden with object variables, though glue code might be 
missing. I considered using a fixed table of three hosts (HTTP, HTTPS, RTSP) 
instead of a linked-list.

I still have not heard much of a real use case for using different port numbers 
in the same VLC instance for the same protocol. Shorter URL is not a good use 
case in my opinion. I won't mention binding addresses again.

-- 
Rémi Denis-Courmont
http://www.remlab.info