I try to transfer binary files between two (Redmine) servers. By the
way, I use the ruby language to do it and all informations are exchanged
through the XML-RPC protocol.
Unfortunatly everything success except that transfered binary files
doesn't work. For instance a word file can not be open.
If I compare the original binary file with the transfered binary file, I
can see that everything is similar except that the 'CR' character is
always replaced with a 'LF' character and 'CR LF' characters are always
replaced with 'LF' characters.
I open the file on local server in this way :
binary_content_to_transfer = File.open(binary_file_path_path,"rb")
{|io| io.read}
I transfer the binary_content_to_transfer with either :string (I also
try with [:base64] but same problem occurs)
On remote server, I save content int this way :
binary_remote_file = File.new(binary_remote_file_path, "wb")
binary_remote_file.write(binary_content_to_transfer)
attachment_file.close
I also try many other adjustments to understand where is the "mistake".
All the tests that I made let me think that the XML-RPC protocol is
responsible of the problem :
- I try to execute directly the same read and write code (without using
the XMLRPC procedure) => The created file is perfectly similar with the
original one.
- I try to use different types for transfering data (:string and
:base64) => Result is the same.
- I try different way of reading and writing files (wb, w, rb, r) =>
Result is worst.
Is anyone has an idea or an alternative solution to transfer binary
files ?
I try to transfer binary files between two (Redmine) servers. By the
way, I use the ruby language to do it and all informations are exchanged
through the XML-RPC protocol.
Unfortunatly everything success except that transfered binary files
doesn't work. For instance a word file can not be open.
If I compare the original binary file with the transfered binary file, I
can see that everything is similar except that the 'CR' character is
always replaced with a 'LF' character and 'CR LF' characters are always
replaced with 'LF' characters.
I open the file on local server in this way :
binary_content_to_transfer = File.open(binary_file_path_path,"rb")
{|io| io.read}
I transfer the binary_content_to_transfer with either :string (I also
try with [:base64] but same problem occurs)
On remote server, I save content int this way :
binary_remote_file = File.new(binary_remote_file_path, "wb")
binary_remote_file.write(binary_content_to_transfer)
attachment_file.close
I also try many other adjustments to understand where is the "mistake".
All the tests that I made let me think that the XML-RPC protocol is
responsible of the problem :
- I try to execute directly the same read and write code (without using
the XMLRPC procedure) => The created file is perfectly similar with the
original one.
- I try to use different types for transfering data (:string and
:base64) => Result is the same.
This one irritates me: by using base64 encoding you should be fine,
shouldn't you?
- I try different way of reading and writing files (wb, w, rb, r) =>
Result is worst.
Is anyone has an idea or an alternative solution to transfer binary
files ?
I'd say that encoding it in some format like base64 would be the right
way to go. That way also text editors don't choke if you use them to
look at the XML message.
This one irritates me: by using base64 encoding you should be fine,
shouldn't you?
I also agree with you, I can even say that I completly agree with you.
I quicky look at source code of XMLRPC protol but I'm afraid that for
base64 there is a stirng conversion that may explain this problem. I'm
not sure of what I'm saying.
Someone know If there is a way to look at the XML message sent. In this
way I can determine if the problem is from the client (emission of the
file) or from the server (reception of the file)
This one irritates me: by using base64 encoding you should be fine,
shouldn't you?
I also agree with you, I can even say that I completly agree with you.
I quicky look at source code of XMLRPC protol but I'm afraid that for
base64 there is a stirng conversion that may explain this problem. I'm
not sure of what I'm saying.
Someone know If there is a way to look at the XML message sent. In this
way I can determine if the problem is from the client (emission of the
file) or from the server (reception of the file)
Dunno that library. Someone else might be able to help. If
everything fails you can use a packet sniffer and look at the network
traffic.
This one irritates me: by using base64 encoding you should be fine,
shouldn't you?
I also agree with you, I can even say that I completly agree with you.
I quicky look at source code of XMLRPC protol but I'm afraid that for
base64 there is a stirng conversion that may explain this problem. I'm
not sure of what I'm saying.
That's probably the issue. CR and LF are line ending characters. And Windows, Linux, and UNIX deal with them differently. If your string conversion happens on a *NIX, Windows applications won't be able to handle the files gracefully, like Word. (Windows expects CR LF, while Linux produces LF, and Mac OS CR; or something like that).
Someone know If there is a way to look at the XML message sent. In this
way I can determine if the problem is from the client (emission of the
file) or from the server (reception of the file)
That should not be the case since a) he is doing reading and writing
in binary and b) base64 encoding does not care whether you have CR or
CRLF as line ending. It does not influence the decoding.
Admittedly we haven't seen the sample code so there might be a quirk
somewhere we haven't thought of yet.
Kind regards
robert
···
2010/1/15 Phillip Gawlowski <pg@thimian.com>:
On 15.01.2010 17:46, Hubert Martin-deidier wrote:
Robert Klemme wrote:
This one irritates me: by using base64 encoding you should be fine,
shouldn't you?
I also agree with you, I can even say that I completly agree with you.
I quicky look at source code of XMLRPC protol but I'm afraid that for
base64 there is a stirng conversion that may explain this problem. I'm
not sure of what I'm saying.
That's probably the issue. CR and LF are line ending characters. And
Windows, Linux, and UNIX deal with them differently. If your string
conversion happens on a *NIX, Windows applications won't be able to handle
the files gracefully, like Word. (Windows expects CR LF, while Linux
produces LF, and Mac OS CR; or something like that).