1. 10 Feb, 2015 3 commits
    • Philipp Schafft's avatar
      Feature: Support PUT with chunked transfer encoding. · 36d10121
      Philipp Schafft authored
      This adds the Transfer-Encoding chunked to PUT support.
      Please test carefully. Will add PUT to Allow: header after testing.
      Have fun.
      Closes: #2088
    • Philipp Schafft's avatar
      Cleanup: unbreak 100-continue a bit. · 79cb147c
      Philipp Schafft authored
      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.
    • Philipp Schafft's avatar
      Fix/Cleanup: Answer SOURCE/PUT requests with a real 200-OK. · d6908eb0
      Philipp Schafft authored
      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.
      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.
  2. 06 Feb, 2015 1 commit
  3. 02 Feb, 2015 3 commits
  4. 01 Feb, 2015 2 commits
  5. 25 Jan, 2015 1 commit
    • Marvin Scholz's avatar
      Cleanup codestyle · 0dfc7c5b
      Marvin Scholz authored
      This commit cleanups codestyle a bit, yet there is still some work to be done
  6. 10 Jan, 2015 2 commits
  7. 05 Jan, 2015 1 commit
  8. 24 Dec, 2014 3 commits
  9. 20 Dec, 2014 1 commit
  10. 18 Dec, 2014 1 commit
  11. 14 Dec, 2014 1 commit
  12. 07 Dec, 2014 1 commit
  13. 02 Dec, 2014 1 commit
  14. 30 Nov, 2014 2 commits
  15. 29 Nov, 2014 1 commit
  16. 28 Nov, 2014 1 commit
    • Philipp Schafft's avatar
      Wow. Mega patch! · a642cac5
      Philipp Schafft authored
      This patch *replaces* the authentication system completly.
      What is new:
       - <authentication> in mount section is now a container object.
       - <authentication> in root and mount section may hold any number of <role>-Tags.
       - <role> tags:
         Those tags define a 'role' and it's ACL rules.
         A role is a instance of an authentication module (see below).
         <role> takes the following options. All but type are optional.
         - authentication related:
           - type: Type of the authentication module (values: anonymous, static, legacy-password, url or htpasswd;
                   symbolic constants in auth.h)
           - name: Name for the role. For later matching. (values: any string; default: (none))
           - method: This rule is only active on the given list of HTTP methods.
                     (list of enum values: methods as recognized by httpp/ (e.g: get,post); default: *)
         - ACL related:
           - allow-method: Allowed HTTP methods.
             (list of enum values: methods as recognized by httpp/ (e.g: get,post); default: get)
           - deny-method: Rejected HTTP methods.
             (list of enum values: methods as recognized by httpp/ (e.g: get,post); default: *)
           - allow-admin: Allowed admin commands. (list of enum values: admin command; default: buildm3u)
           - deny-admin: Rejected admin commands. (list of enum values: admin command; default: *)
           - allow-web: Allowed web pages. (values: empty or *; default: *)
           - deny-web: Rejected web pages. (values: empty or *; default: (empty))
           - connections-per-user: maximum number of simultaneous connections per role and username.
             This is only active on active sources.  (values: unlimited or number of connections; default: unlimited)
           - connection-duration: maximum time of a connection. This is only active on active sources.
             (values: unlimited or number of secounds; default: unlimited)
         <role> takes <option> child tags. <option> tags contain a name and a value option.
         Meaning of <option> tags is up to the authentication module.
       - <role>s are considered to build a stack. If a role returns with AUTH_NOMATCH the next one will be tried.
       - <role>s are tested in this order: mount specific, default mount specific, global, internal fallback.
         Internal fallback is set to allow web/ access via GET, POST and HEAD (only GET supported by this time)
         and rejects all other requests.
       - New authentication module: anonymous
         This module matches all requests. No options taken.
       - New authentication module: static
         This module matches with a static username and password.
         It takes two <option>s. One with name="username" and one with name="password" to set username and password.
         This replaces old style <*-username> and <*-password> tags.
       - New authentication module: legacy-password
         This module matches with a statich password.
         It takes one <option> with name="password" to set password.
         This replaces old ICE and ICY (shoutcast compat mode) authentication.
       - Parsing <authentication> in <mount> with a type set in a special way to allow 100% backward compatibility.
       - Parsing of <source-password>, <admin-password>, <admin-user>, <relay-password> and <relay-user> in global
         <authentication> for 100% backward compatibility.
       - <alias> is now proccessed very early. This enables them to be used for all kinds of requests.
      To Do List & What does not yet work:
       - type="url" auth: mount_add and mount_remove.
         This should be replaced by an unique feature I would call '<event>'.
       - Admin commands manageauth and manageauth.xsl are disabled as they need more review:
         This code needs to be ported to support multiple <role>s per <mount>.
       - url authentication module can not yet return AUTH_NOMATCH.
         This needs to be reviewed and discussed on how to handle this case best way.
       - Default config files needs to be updated to reflect the changes.
         As this is quite some political act it should be done in dicussion with the whole team
         and permission of the release manager.
       - Docs need to be updated to reflect the changes.
      How does it work:
       Code has been changed so that authentification is done early for all clients.
       This allows accessing the ACL data (client->acl) from nearly everywhere in the code.
       After accept() and initial client setup the request is parsed. In the next step
       all <alias>es are resolved. After this the client is passed for authentication.
       After authentication it is passed to the corresponding subsystem depending on kind of request.
       All authentication instances have a thread running for doing the authentication.
       This thread works on a queue of clients.
      Hints for testers:
       - Test with default config.
       - Test with diffrent authentication modules in <mount>.
       - Test shoutcast compatibility mode.
       - Test with new style <authentication> and any amount of <role> (zero to quite some).
       - Test <alias> lookup on all kinds of objects.
       - Test source level credential login into the admin interface.
       - Test shoucast style meta data updates.
       - Test playlist generation.
      Thank you for reading this long commit message. Have fun reading the full patch!
      svn path=/icecast/trunk/icecast/; revision=19358
  17. 21 Nov, 2014 1 commit
  18. 20 Nov, 2014 1 commit
  19. 08 Nov, 2014 1 commit
    • Thomas B. Rücker's avatar
      Applying patch, HTTP PUT requires content-type · 24b7825a
      Thomas B. Rücker authored
      In case of SOURCE we are lenient and thus quite some source clients
      don't send a proper content-type, especially if they only support mp3.
      This was meant to be introduced in 2.4.0 already, sadly we missed it.
      All source clients MUST send proper content-type after migrating to 
      Icecast HTTP PUT protocol.
      closes #2082
      svn path=/icecast/trunk/icecast/; revision=19288
  20. 03 Nov, 2014 1 commit
  21. 31 Oct, 2014 2 commits
  22. 23 Oct, 2014 1 commit
    • ePirat's avatar
      More detailed logging · 461a5375
      ePirat authored
      Add source IP adress to startup and source exit logging, see #2016
      Add mountpoint to some log lines, see #1388
      svn path=/icecast/trunk/icecast/; revision=19250
  23. 18 Oct, 2014 1 commit
  24. 09 Oct, 2014 1 commit
  25. 12 Jan, 2014 1 commit
  26. 02 Apr, 2013 1 commit
    • Philipp Schafft's avatar
      Added support for a default mount. See #1914. · d54c61bf
      Philipp Schafft authored
      The default mount is a block in the config file that contains settings for
      all mount points that do not have a block in configfile themself.
      This is implemented by a <mount type="default">-block.
      In this case the <mount>-block MUST NOT contain a <mount-name>-subblock.
      svn path=/icecast/trunk/icecast/; revision=18902
  27. 29 Mar, 2013 1 commit
    • Thomas B. Rücker's avatar
      Highly experimental HTTP PUT support. ref #1812 · 3c359b62
      Thomas B. Rücker authored
      We are handling it the same as we would handle a SOURCE request.
      Due to legacy code, sender MUST send proper content-type header,
      if content type is not audio/mpeg!
      Can be tested using real-time encoded output and piping it into
      | curl -u username:password -H "Content-type: application/ogg" -T - http://localhost:8000/mountname.ogg
      Note that this example has ZERO timing, so a simple 'cat *.ogg' will fail.
      Whatever feeds the pipe must do it at proper timing for real-time playback!
      svn path=/icecast/trunk/icecast/; revision=18888
  28. 10 Oct, 2012 1 commit
  29. 17 Jul, 2012 1 commit
  30. 26 Nov, 2011 1 commit