I'm using a webservice which spits out very large amounts of data in one piece. The response string can be something like 8MB. While not an issue on a desktop PC, an embedded device goes nuts dealing with an 8MB string object.
I wonder if there is a way to get the response as a stream? Currently I'm using the method like below. I tried using a POST request instead, but SOAP is just more convenient (the response is XML and with the POST I have to convert the plain text reply back to valid XML) and I'd like to stick with it. Is it possible to use a different kind of "Invoke" which won't return strings but streams? Any ideas?
[System.Web.Services.Protocols.SoapDocumentMethodAttribute("MyAPI/MyMethod", RequestNamespace="MyAPI", ResponseNamespace="MyAPI", ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped, Use=System.Web.Services.Description.SoapBindingUse.Literal)]
public string MyMethod(string sID)
{
object[] results = this.Invoke("MyMethod", new object[] { sID });
return ((string)(results[0]));
}
If you use the old ASMX web service client infrastructure, then you're stuck with its limitations. One limitation is that there's no simple way to get the response except as deserialized data.
If it were necessary, then you could use a partial class to override the GetWebResponse method to return your own custom WebResponse. This latter would in turn override the GetResponseStream method to call the base version, consume the stream, then to return a stream containing an "empty" web request (otherwise .NET will choke on a stream with no contents).
You might also try something similar by overriding the GetReaderForMessage method. This is passed a SoapClientMessage instance which has a Stream property that you might be able to use. Again, you'll have to set the stream to something that the web service infrastructure can consume.
The better way to do this is with a WCF client. WCF has much more powerful and easy to use extensibility mechanisms.
In fact, you might not even need to extend a WCF client. You might simply be able to configure it to not have this buffering problem at all.
Any web service call is going to return SOAP, isn't it? I don't think a stream could be serialized into a soap packet to be returned from your service. And even if it could, wouldn't the serialized stream be at least as big as the string itself?
I believe the answer is no, there is no concept of a stream for SOAP.
Probably the simplest answer is to have your method:
Parse your response into segments your mobile device can handle
Cache your response in a application variable as a dictionary of these segments
return an arraylist of GUIDs.
You can then have your client request each of these segments separately via their GUIDs, then reassemble the original response when and handle it all the web services return.
ASMX can't do much about this. WCF's BasicHttpBinding can return a Stream to the caller.
http://msdn.microsoft.com/en-us/library/ms733742.aspx
Related
I need to create a WCF Service that will have a download file function. This WCF will be consumed by a Delphi application.
The problem: The files that will be downloaded are very large and may cause memory problems on Delphi side. So far, I have this code:
[OperationContract]
byte[] DownloadFile(string filePath);
But this code will cause the client app to hold all data in memory which can be an issue.
I have read that WCF is capable of streaming data as you can read at: How to: Enable Streaming
But I have a question regarding this piece of code cut from MSDN:
[OperationContract]
Stream GetStream(string data);
On the client side I want to pass a TFileStream to the function. By using TFileStream every byte read will go directly to the disk. But the function RETURNS a stream and what I want will not be possible since the stream will not a parameter to the function.
How can I download a file from a WCF service directly to the disk?
I have found that relying on "built-in" streaming capability in WCF when working with other (non-.NET) clients is a big source for strange problems...
Basically we solve this kind of scenario by defining:
[OperationContract]
string DownloadFile(string filePath);
The method generates a HTTP(S) url and returns it...
This way any http-capable client can work with the data in a robust fashion...
BEWARE that this makes the server a bit more complicated since you now need to have some mechanism to generate (and serve HTTP GET on) URLs (security, "globally" unique, only usable for a limited time etc.).
BUT the big advantage is that any client out there (mobile or some strange embedded device or whatever you might encounter) will be able to implement this scheme as long as it has http-support available (Delphi has some very good http-client options).
First of all, I'm not sure whether you can consume a streaming WCF service at all in Delphi 2010. If you can, then it works as follows:
The WCF service must be a streamed service, which means that you need to set the transferMode of the binding to Streamed or StreamedResponse. If you want to pass in a string as parameter, it must be StreamedResponse, otherwise, the parameter must be a stream as well.
Having a streamed service also means that there can be no method that does not return a stream or void. It is, for example, not possible to have the following two methods in the same service when it is a streamed service.
Stream GetStream(string s);
int GetInteger(string s);
Also it is not possible to have:
Stream GetStream(string s);
in a service which is configured to be Streamed, as the parameter would have to be a stream, too.
It is not possible to call the method with a stream which will be "filled", even if you make the method take a Stream parameter - not the real instance of Stream is passed back and forth at that point, but the content is actually copied back and forth.
In Delphi you'd get a stream as a result of the method call. You can then copy the contents of that stream into a TFileStream as you'd do if the source was another stream in Delphi. Code for that can be googled. Basically Adriano has posted something that should work. Basically: Read from the source stream, write to the destination stream until everything was read and written, or you could try something like that:
stream1 := wcfServiceClient.GetTheStream();
try
stream2:= TFileStream.Create('to.txt', fmCreate);
try
stream2.CopyFrom(stream1, stream1.Size);
finally
stream2.Free;
end;
finally
stream1.Free;
end;
Again: This works only under the assumption that you can access a WCF streamed service from Delphi as you'd access it from C# or VB.NET.
I've built a simple C# app (.Net 4.0 + WPF) which can send and receive JSON messages via TCP sockets.
As a next step, it should be possible that JavaScript apps on websites and PHP scripts can send and receive JSON messages to/from my app. Is that possible?
Since JS/PHP will use stateless HTTP connections, how should a request to my app work, for example, should the JS/PHP apps send a JSON message to my app and my app response (HTTP response) with a JSON message? Is that even possible? And should I use GET or POST method to send the JSON messages to/from my app?
Hope my questions do not cause too much confusion ;-) I but I appreciate every tip, clarification or feedback you can give me.
Mike
You can accomplish this via a .NET web service using special JSON directives on the web method, e.g.
[ScriptMethod(UseHttpGet = true, ResponseFormat=ResponseFormat.Json)]
public string DoSomething(string param1, int param2)
{
// Do Something
}
When the ResponseFormat.Json property is specified, the data returned will be serialized into the appropriate JSON format. Also note, in order to recieve a true JSON response, you'll need to set your content-type to "application/json" from the requesting application. Otherwise, the method will attempt to wrap the response in XML.
Also, I am enabling a HttpGet on this method so that you can post via a query string to the method, e.g.
http://www.example.com/service.asmx?param1='Hello'¶m2=1;
I'm trying to get the raw data sent to IIS using a HttpHandler. However, because the request is an "GET"-request without the "Content-Length" header set it reports that there is no data to read (TotalBytes), and the inputstream is empty. Is there any way I can plug into the IIS-pipeline (maybe even before the request is parsed) and just kind of take control over the request and read it's raw data? I don't care if I need to parse headers and stuff like that myself, I just want to get my hands on the actual request and tell IIS to ignore this one. Is that at all possible? Cause right now it looks like I need to do the alternative, which is developing a custom standalone server, and I really don't want to do that.
Most web servers will ignore (and rarely give you access to) the body of a GET request, because the HTTP semantics imply that it is to be ignored anyway. You should consider another method (for example POST or PUT).
See this question and the link in this answer:
HTTP GET with request body
I have a need to override the receipt of a raw HTTP request as it is being communicated to an IIS server. I want to know if this is possible.
We have a client who sends huge Web Service calls (tens of Mb) and we want to start acting on portions of those calls as they are being received (in order to get a faster total time of execution for the Web Service call).
Currently, using normal web service methods, our application code is handed the Web Service call after it is totally received.
I realize this isn't the ideal way of handling Web Services, and we're not building our business on this, but we do have an need that we're trying to fill for a limited range of customers.
I have created a handler that implements IHttpHandler, but it appears that at this point in the process pipeline, the Request has been fully received by IIS (which doesn't get us any benefit over our current model). That is, I can read the InputStream directly, but the full request has already been transferred over the wire before I have access to this stream.
I think the answer is that I have to code an ISAPI filter to get this far down, but I don't have the skills to do this in C/C++. Does anyone know if there's another way I can do this without the ISAPI filter route?
An acceptable answer could be, "You have to do this as and ISAPI filter, to do it in C#, check this doc".
You can use a custom HttpModule to hook almost any part of the IIS pipeline. They work in both IIS 6 (under ASP.NET) and are the primary extension mechanism in IIS 7.
There are plenty of examples of building ISAPI filters, but none in C#. I am sure it is possible, but not practical and not without lots dirty tricks.
Your C# investment will hold up well in C++, let me know if you need help. By the way, I recommend you invest in the my standard trio - try to keep up a healthy knowledge of C#, C++ and Java.
I also recommend you consider Apache modules, they may offer more overall flexibility. This is what I would do:
host these web services off of IIS - you never know when IIS will bite you by resetting the application.
Use WCF services, host these from Windows services, use redirection to route the service to the WCF service.
Consider writting a raw sockets application. This one would implement the minimal WS:* protocol to your service and act as a proxy for the real service. When the proxy detects that the inbound message is exceeding a threshold it would begin analyzing the message to extract out what it could process right away.
The result would be standard WCF (through proxy) for smaller messages and non-standard processing for everything else.
Let me know if I can help you build it - this is the kind of thing I like to do...
Oh - and I recall now that WCF is completely configurable. You will be able to provide your own handlers for a variaty of layers and resolve everything from within managed code after all.
Short Version
The solution is to use HttpRequest.GetBufferlessInputStream.
Long Version
The issue is that if you attempt to use:
Request.InputStream
or Request.Form
or Request.Files
you must wait until the whole request has been received before it returns a Stream object. In contrast, the GetBufferlessInputStream method returns the Stream object immediately. You can use the method to begin processing the entity body before the complete contents of the body have been received.
This method can be useful if the request is uploading a large file and you want to begin accessing the file contents before the upload is finished. However, you should only use this method for scenarios where you want to take over all processing of the entity body. This means that you cannot use this method from an .aspx page, because by the time an .aspx page runs, the entity body has already been read.
The only downside, and it is a huge downside, is that you are now reading the Request.InputStream. This means you have to handle the MIME multiparts, and the base64 encoding, yourself.
Example (untested) code
UploadFile.ashx
public class Default : IHttpHandler
{
public void ProcessRequest (HttpContext context)
{
var request = context.Request;
var stm = request.GetBufferlessInputStream(true); //true --> disable web.config limits on request size
if (!stm.CanRead)
throw new Exception("Request input stream is not readable");
//Setup the buffer we'll be shuffling stream data into
int bufferLength = 16 * 8040; //use a multiple of 8040 bytes, because SQL Server uses pages of 8040 bytes. And because i'm saving it into SQL Server.
byte[] buffer = new Byte[bufferLength];
int bytesRead;
bytesRead = stm.Read(buffer, 0, buffer.Length);
while (bytesRead > 0)
{
SavePiece(buffer, bytesRead); //whatever you want to do with it
bytesRead = stm.Read(buffer, 0, buffer.Length);
}
}
private void SavePiece(byte[] buffer, int bufferLength)
{
//It's all going to be multipart mime encoded nonsense.
//Good luck!
}
public bool IsReusable { get { return false;}
}
Bonus Reading
How can I decode a multipart HTTP response?
Are there any multipart/form-data parser in C# - (NO ASP)
https://stackoverflow.com/a/21689347/12597 (example usage of the StreamContent class in .NET)
MSDN: StreamContent Class
I'm programming a service for a program that uses HTTP post/get requests, so I handle all incoming requests with a hook method that takes a System.IO.Stream and returns a System.IO.Stream.
When I parse the incoming request (contained in an HTML form) by converting to a string and then using System.Web.HttpUtility.ParseQueryString(string), it seems to automatically URL-decode the data. When I return a file path (a Windows UNC, not going to explain why I do that), I initially URL-encoded the string before converting to a stream and returning it using a return-statement, the client seems to get a doubly-coded string.
So, just to be sure, does WCF automatically URL encode/decode streams for me as part of using System.ServiceModel.WebHttpBinding?
Apparently, it does:
"For RESTful services, WCF provides a binding named System.ServiceModel.WebHttpBinding.
This binding includes pieces that know how to read and write information using the HTTP and HTTPS transports, as well as encode messages suitable for use with HTTP."
from here.