I'm trying to upload a binary (mp3) file using an HTTP post session.
The file is read-out using File.ReadAllBytes and the content bytes are set on the session data parameter using protocol.SetParameterBinary
To test this upload I've created a dummy mp3 file containing some simple binary content (Hex 02 01 00 02 00). Using this file I can easily perform an upload via the Web Interface and compare the request payload with the payload send via protocol communication.
The request via the Web Interface gives the expected result:
However when performing the same call via protocol it seems the payload data is completely different and I'm even losing a byte along the way.
I'm certain the protocol.SetParameterBinary call works correctly and my session content parameter is filled in with the correct binary data (I've performed a Set and Get count on the bytes and the result was identical: 5 bytes)
I have a feeling SLPort is changing the content somehow by possible adding some extra encoding to the data, but it would be nice if someone could confirm this?
I've implemented and performed the same HTTP upload request directly from QAction (bypassing SLPort) and everything works perfectly, which only confirms my SLPort suspicion.
Am I missing something, or can somebody confirm the above?
Hi Jelle,
Internally there are 2 types of parameters: a double or a string. In this case a string is being used and is interpreted as such. The bytes that are sent are tried to be looked at as characters and that can cause "translation" problems when going back and forth between (unicode) character encodings and their bytes, which is what you're probably seeing here. Something that might be tried is to make your protocol a unicode protocol, but this is just a long shot and no guarantee at all that this will work.
Regards,
Hi Laurens, thanks for the feedback. Unfortunately the protocol is already defined as ‘unicode’.