Derek McGowan

Excellent point, any newly created stream which will send data should have a content-type. Types - `application/vnd.libchan.send+msgpack5` - Encoded messages in msgpack5 - `application/vnd.libchan.recv+msgpack5` - Encoded responses in msgpack5 -...

Updated based on original feedback, still need to update for content types

I think the ":status" as used currently in spdy and defined in HTTP is missing here. I will add ":status" as the response header which should contain an HTTP status...

Hmm looking more at the streams interface, I am thinking streams will need to have a function to handle the reply unless it would be expected the stream provider would...

Finally pushed the update. Going to revive this and get this work completed.

Updated with last comments and content types Pushed an update to the streams library in support of this change https://github.com/dmcgowan/streams/commit/f02a9e7b00caabc2b0bc3d166a329354ea57ce4d. This will enable proper content type handling by libchan.

I do expect this to work as well with the latest encoding change. I would try to make this test work with the `spdy` package since that will hit the...

@stevvooe something still needs to be done to resolve this issue. Either documentation needs to be clear that the primitive libchan channel does not have go semantics, libchan protocol needs...

Adding this to 0.2.0 along with updated protocol. The semantics should be clearly defined along with the differences between Go channels. The 0.2.0 protocol PR attempts to lay out it...

@mcollina I don't think the use of pointers here is anything that would cause compatibility issues. However I am not sure I agree with the general pattern of having a...