We should first shut down TLS so we can signal the other end a clean shutdown
in contrast to a socket failure.
Big thanks to wget(1) to find it. Fantastic tool.
This generates error pages based on IDs. This allows to reuse errors
and add more advanced information to them.
This patch also makes Icecast send in plain text OR HTML based
on the clients Accept:-string.
This allows ICY source clients to log in again with 2.4.x-style config.
ICY does not provide a username. Therefore the username was unset.
This patch sets the username for ICY source connections and allow them
to be handled as if a username was provided.
Configuration tag <shoutcast-user> was added to select the username to set
to. This defaults to "source".
ban and allow file support has been moved into a generic implementation
that can be re-used by later code such as proxy matching or other
blacklisting.
See: #1959
This tries to unbreak the 100-continue thing a bit.
Proper headers are send in case of 100-continue. Also the 200 OK
was moved to the end of the stream.
The client may even be reused. But I'm not sure we only do
'End of stream' in cases we are not on an undefined state of the
client. Do we as of now support anything that give us EOS without
a fatal socket state (error or shutdown)?
At least this unbreaks 100-continue with active TLS that was broken
as hell as we sent the header in clear over the socket. Not checking
if it was transmitted completly or something. Using lowlevel socket
calls (in contrast to the connection level calls that would have
handled the TLS just fine).
While this seem sto be a huge improvement to the situation I kindly
ask you to do a lot testing on this. Both with SOURCE as well as
PUT clients.
We have answered SOURCE/PUT requests with a simple
"HTTP/1.0 200 OK\r\n\r\n" while we should answer with complet
headers. This commit corrects this.
Interoperability:
This will work for two classes of clients:
* Super dumb ones not checking the response and will just send
data and hope the socket is still open.
* Those with a real parser.
* Shoutcast clients (indepnded code path).
* All libshout, curl, wget, ... based clients.
This *could* break:
* Clients that check for the exact returned message. However
as we start with the same string this should work.
Only client that check for the string including the End-of-header
CRLF sequense may break.
Please test careful before release.
This allows the usage of RFC 2817 style upgrade commands.
This is not correctly announced yet.
Can hardly be tested as most clients do not support this.
Will be helpful with TLS support in libshout.
See: #2159, #2152
This allows <resource> (former <alias>) to have only one of the
attribues source and destination. In that case other parameters
will be applied to the client but uri is not mapped.
See #2097