Playing ICECast2 stream with jPlayer + Aurora

[sigaev-pro]

Hi,

I'm tring to play ICECast ctream with jPlayer and Aurora. I'm including following files

aurora.js ogg.js vorbis.js

jPlayer is configured to use aurora

solution: "aurora", auroraFormats: "oga"

But I have following errors in my console

In my ICECast2 log I have following entries

[2015-07-20 17:56:03] EROR connection/_handle_connection Wrong request type from client [2015-07-20 17:56:29] INFO format-vorbis/initial_vorbis_page seen initial vorbis header [2015-07-20 17:56:46] EROR connection/_handle_connection Wrong request type from client [2015-07-20 17:56:58] EROR connection/_handle_connection Wrong request type from client [2015-07-20 17:57:05] INFO source/source_main listener count on /source now 1 [2015-07-20 17:57:06] INFO source/source_main listener count on /source now 0 [2015-07-20 17:57:46] EROR connection/_handle_connection Wrong request type from client

So ICECast2 does not support HEAD requests.

So how I can get aurora decoder working without initital HEAD request?

[sideeffffect]

@ph3-der-loewe over at #2223 suggests that this is a problem on aurora.js side

[sideeffffect]

@ph3-der-loewe

Seems that "aurora.js" uses HEAD to get the total length in bytes of the resource and then does GET requests on chunks. This is totally wrong to begin with:

• It MUST NOT assume that HEAD and any later GET requests to the same URI will result in the same object. At least ETags must be checked.
• It MUST NOT assume that the length is known to the server and that the length is finite.
• It SHOULD (read: MUST) use the Content-Range:-reply-header to find out about the length if at all (the header MAY return "*" for unknown length).
• HEAD requests MAY omit content related headers at will.
• Chunking like this seems to be a very strange thing to do. I hardly see any reason for this.

So: Even if we would provide HEAD support, this would not solve the referenced problem as the problem is the application 0) miss-implementing HTTP, 1) does not support infinite resources AKA streams anyway. From what I have seen in the code I would guess that a perfectly HTTP conforming server can also break it in other ways. @tbr I would suggest to close this ticket for now as this seems to be related more to the original problem than to HEAD support. Also considering that for a month nobody came up with a reason why HEAD is needed. If HEAD support is a goal I would like to have a "fresh" and "clean" ticket for it (including a reason why it is needed).