[PATCH] Send final status code only after the source data was received
Icecasts new PUT support should comply with the HTTP protocol, currently this isn't the case since it sends the status line (200 OK
) right after the source clients connects, but should only send it at the end of the request. Error codes can be sent earlier, since they indicate that transmission of data is finished.
An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body.
With the success code 200 (and others like 201) this is not the case, since it would indicate Success until all data is received which makes no sense.
If a source client needs a indicator when to start sending data, it should set the Expect: 100-continue
header and wait for the 100 Continue
reply from the server.
Here is an example what Icecast currently sends:
> PUT /testsendung.mp3 HTTP/1.1
> Authorization: Basic REDACTED=
> Host: example.com:8001
> Accept: */*
> Content-Type: audio/ogg
> Ice-Public: 1
> Ice-Name: Teststream
> Ice-Description: This is just a simple test stream
> Ice-URL: http://example.org
> Ice-Genre: Rock
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
> [ Some stream data sent by client ]
< HTTP/1.0 200 OK
> [ More stream data sent by client ]
Instead Icecast should send:
> PUT /testsendung.mp3 HTTP/1.1
> Authorization: Basic REDACTED=
> Host: example.com:8001
> Accept: */*
> Content-Type: audio/ogg
> Ice-Public: 1
> Ice-Name: Teststream
> Ice-Description: This is just a simple test stream
> Ice-URL: http://example.org
> Ice-Genre: Rock
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
> [ Stream data sent by client ]
< HTTP/1.1 200 OK
< Content-Length: 0
< Connection: close
<
* Closing connection 0
(Additionally note that Icecast mixes HTTP Protocol)
This patch fixes the behavior so that it matches the second one. I am not completely sure if I fixed it the right way, since the file server internals are not 100% clear to me. I marked it was critical since I think we should address this asap, so that (new) source clients do not start to rely on this (wrong) behavior.