I have made a SOAP API using WSDL, and I need to transfer bytes of a file from client to the server of the API. I am using unsignedBinary[] array type in the WSDL to describe the data to be passed. The WSDL description is as follows:
<complexType name="TByteArray">
<complexContent>
<restriction base="soapenc:Array">
<sequence/>
<attribute ref="soapenc:arrayType" n1:arrayType="xs:unsignedByte[]" xmlns:n1="http://schemas.xmlsoap.org/wsdl/"/>
</restriction>
</complexContent>
</complexType>
I am trying to send the data in raw bytes, which is giving error.
Now I am doing a base64 encode while sending the binary data using the soap API call.
It works fine if I send the data using PHP Client, but it is not working when I use a Delphi application to send the data.
Do you think that converting the binary data to base64 is making the Delphi application not allow to send the data?
unsignedByes is not allowed to transfer to Base 64? Does anyone know the details of this?
Thanks for you valuable comments, but i have solved this problem.
I removed the following code and transferred the binary on the "type:xs:hexbinary"
<part name="abData" type="xs:hexBinary"/>
and it works like magic.
It converts the binary automatically to hex and on receiving on the server it again converts to binary on it's own...
Thanks.
Related
I develop for iOS primarily and I'm flirting with Rails as I divorce PHP, so I'm having my first encounter with Paperclip.
Looking for a simple example of the request format Paperclip is expecting, it seems that everyone is encoding their images to base64 on the client before sending the data to Rails. But when their Rails receives the data, they just unpack the base64 and pass the image into paperclip.
Why do people encode and decode their image data when sending it to rails?
Is there any way that a plaintext png byte stream would get corrupted where base64 wouldn't?
Or is this just an early optimization for security reasons?
Here is a related question about why base64 encoding is used Why do we use Base64? and here is a quote from there that relates to embedding images in html.
Historically it has been used to encode binary data in email messages where the email server might modify line-endings. A more modern example is the use of Base64 encoding to embed image data directly in HTML source code. Here it is necessary to encode the data to avoid characters like '<' and '>' being interpreted as tags.
Can anyone please help provide a simple example to encode data for protobuf in dart...
Fully understand how to decode the protobuf data received from a server in the browser...
MyMessage.fromBuffer(binaryDataList);
Not sure how to encode the data to protobuf in the browser to send back to the server..
You can use writeToBuffer() on your message to get a list of bytes that you can send via AJAX or Websockets. The returned buffer is of the type Uint8List that implements List<int>.
I am using Delphi 7's HTTPReqResp component to send a digitally signed SOAP XML Document to a HTTPS web service. I use Eldos XML BlackBox and have set all the transformAlgorithms, CanonicalizationMethod, signaturemethod, etc. to the ones the web service requires and have confirmed this with a tech support officer.
I have validated the signature using XML BlackBox and also this XML Verifier website.
Both ways confirm the signature is correct. However, when I send the XML document via HTTPReqResp.execute, the response I get back is BadSignature (The signature value is invalid).
Originally, I received back a different error messages due to XML errors (malformed, etc.). It appears that the service will do all the standard formatting checks first, then it will attempt to validate the signature. Since I get back the BadSignature response, the rest of the XML must be correct.
I suppose I have 2 questions here.
Does the HTTPReqResp component alter the XML.
Is it likely the webservice alters the XML.
The site is using Access Manager WebSEAL.
It's very likely that the receiving partner is getting a modified document somehow. Some minor modifications shouldn't affect the signature (that's the idea, at least) so you may want to check the following:
"Recommended" encoding used by the receiving partner. A very annoying practice by some receiving partners is to favor one form of encoding and completely ignore others. XML signatures should use utf-8 but I've seen servers that only accept iso-8859-1
Make sure you don't accidentally change encoding after signing.
Verify that the receiving partner is using a sane canonicalization method.
Verify with your receiving partner that no extraneous elements are being added to your document.
Also, have you tried to post this using the SecureBlackBox components? They also have an HTTP client that can do SSL, and that can be used to also verify the bytes being sent through the wire.
I'm using Axis2 1.6.1 to create a webservice, both the server and the client. The webservice is pretty simple: it receives two strings and returns an array of bytes. The issue I'm finding is that the client is sending the request encoded as UTF-8, so when I send a text in Spanish with accents, they get replaced by some strange characters. How can I force the client to use UTF-16?
Thanks
Jose Luis
you need to set it as a service client property. Please have a look at here[1].
[1] http://wso2.org/library/230
I am currently putting together a rails-based web application which will only serve and receive data via json and xml. However, some requirements contain the ability to upload binary data (images).
Now to my understanding JSON is not entirely meant for that... but how do you in general tackle the problem of receiving binary files/data over those two entrypoints to your application?
I suggest encoding the binary data in something like base64. This would make it safe to use in XML or JSON format.
http://en.wikipedia.org/wiki/Base64
maybe you could have a look on Base64 algorithm.
This is used to "transform" everything to ascii char.
You can code and decode it. It's used for webservices, or even on dotnet Serialization.
Hope this helps a little.
Edit: I saw "new post", while posting, someone was faster.Rails base64
If you are using Rails and json and xml than you are using HTTP. "POST" is a part of HTTP and is the best way to transform binary data. Base64 is a very inefficient way of doing this.
If your server is sending data, I would recommend putting a path to the file on the server in the XML or JSON. That way your server doesn't have to base64 encode the data and your client, which already supports HTTP GET, can pull down the data without decoding it. (GET /path/to/file)
For sending files, have your server and/or client generate a unique file name and use a two step process; the client will send the xml or json message with fileToBeUploaded: "name of file.ext" and after sending the message will POST the data with the aforementioned filename. Again, client and server won't have to encode and decode the data. This can be done with one request using a multi-part request.
Base64 is easy but will quickly chew up CPU and/or memory depending on the size of the data and frequency of requests. On the server-side, it's also not an operation which is cached whereas the operation of your web server reading the file from disk is.
If your images are not too large, putting them in the database with a RoR :binary type makes a lot of sense. If you have database replicas, the images get copied for free to the other sites, there's no concern about orphaned or widowed images, and the atomic transaction issues become far simpler.
On the other hand, Nessence is right that Base64, as with any encoding layer, does add network, memory and CPU load to the transactions. If network bandwidth is your top issue, make sure your web service accepts and offers deflate/gzip compressed connections. This will reduce the cost of the Base64 data on the network layer, albeit at the cost of even more memory and CPU load.
These are architectural issues that should be discussed with your team and/or client.
Finally, let me give you a heads up about RoR's XML REST support. The Rails :binary database type will become <object type="binary" encoding="base64">...</object> XML objects when you render to XML using code like this from the default scaffolding:
def show
#myobject = MyObject.find(:id)
respond_to do |format|
format.xml { render => #myobject }
end
end
This works great for GET operations, and the PUT and POST operations are about as easy to write. The catch is the Rails PUT and POST operations don't accept the same tags. This is because the from_xml code does not interpret the type="binary" tag, but instead looks for type="binaryBase64". There is a bug with a patch at the Rails lighthouse site to correct this.