Hi, A question for the HTTP Basic auth for icecast2: what is the username to use when doing such authentication. The related line in the login is: Authorization: Basic <base64 encoded string> where the <base64 encoded string> in its original form is: username:password now, what username is used? in the config file for the icecast2 server, one can only set the password (except for the <changeowner> element, but that seems to be not related to the source login issue). Also, in the current CVS, I see a sort of mixure in the HTTP-style login protocol. The whole login sequence seems like the following: SOURCE /<mountpoint> HTTP/1.0 Content-Type: <application/x-ogg or audio/mpeg> Authorization: Basic <base64 encoded string> User-Agent: <user agent> ice-name: <name> ice-url: <url> ice-genre: <genre> ice-bitrate: <bitrate> ice-public: <public> ice-description: <description> <p>this seems like a mule, sort of half-HTTP, half-ICE. is this the intended login protocol for the beta release? <p>Akos --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 11:35 PM 8/19/2002 +0200, you wrote:>Hi, > >A question for the HTTP Basic auth for icecast2: what is the username to >use when doing such authentication. The related line in the login is: > >Authorization: Basic <base64 encoded string> > >where the <base64 encoded string> in its original form is: > >username:password > >now, what username is used? in the config file for the icecast2 server, >one can only set the password (except for the <changeowner> element, but >that seems to be not related to the source login issue).looking at the code, it seems that the user names are actually hard-coded as "source" and "relay", so connecting a source client would specify source:hackme base64 encoded....I don't know if this is just a placeholder or in fact the way it is intended to work for real...Michael probably would answer that best... <p>>Also, in the current CVS, I see a sort of mixure in the HTTP-style login>protocol. The whole login sequence seems like the following: > >SOURCE /<mountpoint> HTTP/1.0 >Content-Type: <application/x-ogg or audio/mpeg> >Authorization: Basic <base64 encoded string> >User-Agent: <user agent> >ice-name: <name> >ice-url: <url> >ice-genre: <genre> >ice-bitrate: <bitrate> >ice-public: <public> >ice-description: <description> > > >this seems like a mule, sort of half-HTTP, half-ICE. is this the intended >login protocol for the beta release?actually, I think this is completely valid HTTP syntax..I don't think there is anything preventing you from implementing a different method (i.e. SOURCE as opposed to GET or POST) and the ice-* headers are simply HTTP headers specific to a SOURCE request....The ICE part of the protocol is what the server responds back with....I think at least....I could be wrong... oddsock <p>>Akos <p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Michael Smith wrote:> Currently, "source". Other suggestions welcome.I see. I guess the current working semantics don't need anything more complicated. If the need rises to provide more complex access control, userid / password pairs could be defined in the icecast config file. e.g.: user1 / password1 allowed to connect as source /source1* user2 / password2 allowed to connect as source /source2* or something like that. this would make it possible to give different users a safe way to provide their sorces to the same server, but not interfere with each other.> I'm not sure. I understand your misgivings about it being > not-quite-HTTP, but I'm not sure if there's a better solution. I > changed the authentication to using HTTP auth because HTTP _does_ > provide a standard way to do it, but the rest it doesn't - and > we still want that information (the rest of it is optional, > remember, leaving SOURCE as the only mandatory non-HTTP part. I > considered using PUT instead of SOURCE, and I could still be > swayed on that, but the semantics seemed sufficiently different > to keep them seperate). > > Ideas are welcome.Looking at the HTTP 1.1 RFC 2616: ection 5, Request: Request = Request-Line ; Section 5.1 *(( general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 4.3 ection 5.1, Request-Line: Request-Line = Method SP Request-URI SP HTTP-Version CRLF Method = "OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Section 9.8 | "CONNECT" ; Section 9.9 | extension-method extension-method = token we can think of SOURCE as an extension-method. regarding responses to different methods, the RFC says that a 501 (Not Implemented) response should be given to all unimplemented methods (I wonder if this is done so), and that "methods GET and HEAD MUST be supported by all general-purpose servers" (most probably done already). for the headers: ection 4.5, General Header Fields general-header = Cache-Control ; Section 14.9 | Connection ; Section 14.10 | Date ; Section 14.18 | Pragma ; Section 14.32 | Trailer ; Section 14.40 | Transfer-Encoding ; Section 14.41 | Upgrade ; Section 14.42 | Via ; Section 14.45 | Warning ; Section 14.46 ection 5.3, Request Header Fields request-header = Accept ; Section 14.1 | Accept-Charset ; Section 14.2 | Accept-Encoding ; Section 14.3 | Accept-Language ; Section 14.4 | Authorization ; Section 14.8 | Expect ; Section 14.20 | From ; Section 14.22 | Host ; Section 14.23 | If-Match ; Section 14.24 | If-Modified-Since ; Section 14.25 | If-None-Match ; Section 14.26 | If-Range ; Section 14.27 | If-Unmodified-Since ; Section 14.28 | Max-Forwards ; Section 14.31 | Proxy-Authorization ; Section 14.34 | Range ; Section 14.35 | Referer ; Section 14.36 | TE ; Section 14.39 | User-Agent ; Section 14.43 ection 7.1, Entity Header Fields entity-header = Allow ; Section 14.7 | Content-Encoding ; Section 14.11 | Content-Language ; Section 14.12 | Content-Length ; Section 14.13 | Content-Location ; Section 14.14 | Content-MD5 ; Section 14.15 | Content-Range ; Section 14.16 | Content-Type ; Section 14.17 | Expires ; Section 14.21 | Last-Modified ; Section 14.29 | extension-header extension-header = message-header an in section 4.2, Message Headers: message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string> (missing definitions can be found in section 2.2, Basic rules) the spec says that all three header field categories can be extended, but basically defines a fallback mechanism: if a header is not recognized as a general-header, than it is most probably a request-header. if it is not recognized as a request-header, than most probably it is an entity-header. Moreover, in section 7.1: The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Thus it seems that the ice-* headers can be thought of as extension-header fields. Another question: will the Host: request header be supported? (Thinking of virtual streaming servers.) <p>Akos --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 11:35 PM 8/19/02 +0200, you wrote:>Hi, > >A question for the HTTP Basic auth for icecast2: what is the username to >use when doing such authentication. The related line in the login is: > >Authorization: Basic <base64 encoded string> > >where the <base64 encoded string> in its original form is: > >username:password > >now, what username is used? in the config file for the icecast2 server, >one can only set the password (except for the <changeowner> element, but >that seems to be not related to the source login issue).Currently, "source". Other suggestions welcome.> >Also, in the current CVS, I see a sort of mixure in the HTTP-style login >protocol. The whole login sequence seems like the following: > >SOURCE /<mountpoint> HTTP/1.0 >Content-Type: <application/x-ogg or audio/mpeg> >Authorization: Basic <base64 encoded string> >User-Agent: <user agent> >ice-name: <name> >ice-url: <url> >ice-genre: <genre> >ice-bitrate: <bitrate> >ice-public: <public> >ice-description: <description> > > >this seems like a mule, sort of half-HTTP, half-ICE. is this the >intended login protocol for the beta release?I'm not sure. I understand your misgivings about it being not-quite-HTTP, but I'm not sure if there's a better solution. I changed the authentication to using HTTP auth because HTTP _does_ provide a standard way to do it, but the rest it doesn't - and we still want that information (the rest of it is optional, remember, leaving SOURCE as the only mandatory non-HTTP part. I considered using PUT instead of SOURCE, and I could still be swayed on that, but the semantics seemed sufficiently different to keep them seperate). Ideas are welcome. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.