Sending header with no payload - For SharpRTSP Project and rtsp-over-http protcol

[RogerHardiman]

Hi For the SharpRTSP Project (on github) I've implemented the protocol called RTSP-Over-HTTP which dates back to 1999.

The protocol uses a long running HTTP GET connection which requires the following a) When the HTTP GET is received, we send a reply with HTTP Headers (there is no payload bytes to send yet) and leave the TCP socket open b) The reply Header must not used Chunked Transfer and most not have a Content-Length. (It is based on HTTP/1.0) c) At some point in the future we will write bytes to the OutputStream. It is not chunked. It is just raw bytes using a protocol where the receiver can determine the start/end of RTSP messages

I've made the changes and wanted to ask if a PR would be OK? The changes are

1. Allow ContentLength to be set to -1 (currently negative values will throw an exception)
2. If the ContentLength is -1, we do not add ContentLength to the HTTP Headers
3. Add a SendHeaders() function which works by doing Reply.OuputStream.Write() of Zero Bytes so HTTP Reply Headers are sent

Would you consider this as a PR, or is this changing the library too much?

[PJB3005]

Oops, missed this issue when you posted it.

This doesn't seem too bad to have in the library, as long as the protocol is like "you do this, the TCP connection is now yours to do whatever with." Instead of having it be via some magic incantation of ContentLength=-1 I'd just have an explicit function that clearly says "here be demons" though.

[RogerHardiman]

That sounds sensible. It could be a setting to force a HTTP/1.0 mode is the way to enable this feature. HTTP/1.0 does not support ContentLength

For info, here are my local patches. A patch to allow the ContentLength of -1 (which would change to something that sets the HTTP Reply to 1.0) A patch to allow us to write the HTTP Headers when we don't have any payload bytes to send yet A patch to allow us to return HTTP/1.0 in the reply

and