[icecast] details of HTTP Basic auth for icecast2

[Akos Maroy]

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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.