This switches the behaviour introduced with the last commit
so that now the admin folder is only checked for includes if
in the specified path none is found.
This adds support for including xslt files that are in the admin
directory in an xslt file which is in the webroot, without having to
specify the full path.
For example:
<xsl:include href="includes/head.xsl"/>
will look inside the admin directory (foo/bar/admin/includes/header.xsl)
and include it, if it's found. If not it will as usual look for it in
the directory where the xslt file is located. This enables us to have
common files like the header, footer, json stuff, etc. in the admin
directory, so we don't need to have an extra copy in the web folder.
Note:
The configuration value for the admin directory is requested
every time an xslt is requested (if not in the cache).
Additonally it should be noted that the includes are not cached.
We haven't been using VS6 to build Icecast for a while.
We won't be bringing back the management UI, as everything is now
accessible through either web-ui or start menu.
Proper Windows service handling remains on todo list for 2.5.0.
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 exposes the TLS status as <tls> tag in the <listener> tag.
The tag contains a bool ("true" or "false"). TLS mode, version and
other parameters are out of the scope of this tag and may be added
as independed tags in later commits.
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 adds to all responses:
* "Accept-Encoding: identity"
* "Connection: close"
* "Allow: GET, SOURCE" or "Allow: GET" (on admin pages)
This is to generate some infrastructure for Icecast to tell futur
source clients what is supported.
"Upgrade: TLS/1.0" should be added later when upgrade support is present.
See: #2152
This (hopefully) fixes a memory leak that caused active and
pending ypdata_t objects to be not freed up on server shutdown
or config reload.
To testers: please enable yp submission and restart and SIGHUP
your instance several times with loglevel set to warning or higher.
Each time after shutdown or SIGHUP check your log for one of the
following two warnings:
* 'active ypdata not freed up'
* 'pending ypdata not freed up'
Those warnings must not be in the log. If you spot one please report.
This adds info to the blocks about their size.
Also added two more blocks:
* for experimental features such as in private branches or
or feature branches. This is for command IDs that are going to
be merged with master some day. At merge they need to be changed
and put into the regular position.
* for private features that are not going to be merged into master.
e.g. specific features for a very specific user that are not
useful for general audiance.
This should help keeping stuff sorted and largey reducing the risk
of command ID collissions on merges of branches.
Also this should make the merger's job a little bit more easy as
there are less likely any conflicts on merge if someone else got
a number closeby and those change is within the diff's context lines.
