I am trying to upload MS-Excel file through WCF-REST Service.
I used the solution given in below post:-
RESTful WCF service image upload problem
My POST Method is declared as:
[OperationContract]
[WebInvoke(Method = "POST", UriTemplate = "/RFQ")]
[WebContentType("application/octet-stream")]
void UploadRFQDoc(Stream fileContents);
When I debug, stream content is fine till the call goes, and when I attach service to debug, Stream fileContents parameter becomes null , and service returns with [Bad Request]. I am not sending large file (it is just 50 KB). I am using HttpClient to call the Post.
Here are the client code(RestClient is HttpClient).
protected void Post(string uri, Stream stream, int length)
{
var content = HttpContent.Create(output => CopyToStream(stream, output, length), "application/octet-stream", length);
Uri relativeUri = new Uri(uri, UriKind.Relative);
var resp = RestClient.Post(relativeUri, content);
ProcessResponse(resp);
}
void CopyToStream(Stream input, Stream output, int length)
{
var buffer = new byte[length];
var read = input.Read(buffer, 0, Convert.ToInt32 (length));
output.Write(buffer, 0, read);
}
Any clue what else can go wrong.
Many Thanks.
[WebContentType("application/octet-stream")] attribute was unnecessary here. I commented it out, and all worked fine :).
Related
I am Migrating one of projects to .NET CORE MVC ,
Previous code had API to Upload document, re-written same
Rewritten Above Code to below code , used "using
Microsoft.AspNetCore.Mvc.WebApiCompatShim" to get HttpRequestMessage
[Older Code: Working Fine in .NET FRAMEWORK]
public HttpResponseMessage UploadFile(string filetype)//old code
{
Stream file = Request.Content.ReadAsStreamAsync().Result;
string id;
id = DocumentHelper.SaveDocument(filetype, file);
return Request.CreateResponse<string>(HttpStatusCode.OK, id);
}
public HttpResponseMessage UploadFile(string filetype)//Re-Written Code
{
HttpRequestMessageFeature requestMessage = new HttpRequestMessageFeature(Request.HttpContext);
HttpRequestMessage httpRequestMessage = requestMessage.HttpRequestMessage;
Stream file = httpRequestMessage.Content.ReadAsStreamAsync().Result;
string id;
id = DocumentHelper.SaveDocument(filetype, file);
return httpRequestMessage.CreateResponse<string>(HttpStatusCode.OK, id);
}
Quickwatch for ReWritten Code when trying to read content
[1]: https://i.stack.imgur.com/cc4AF.png
Tried using Request.Body with stream reader, and enabled buffering.
Any Pointers How to read the stream from Microsoft.AspNetCore.HTTP.HttpRequest,I AM TRYING TO AVOID async function that would force me to change return type
I have a working WCF REST service (.NET 4.0) for down-streaming the images. But when this service is published to the Azure Website (.NET 4.5) the images loaded are randomly corrupt. This never happens locally, or even on a within a domain.
On Azure it's not consistent. Sometimes it loads, sometimes it doesn't. You can check out the corruption here:
http://telproabrdev.azurewebsites.net/logo/vyrobce/get?id=4bced4ee-7162-45a3-a495-7764305e2d56&format=PNG
This is my code (basically):
Contract:
[OperationContract]
[WebGet(UriTemplate = "get?id={id}&format={format}",
RequestFormat = WebMessageFormat.Xml,
ResponseFormat = WebMessageFormat.Xml,
BodyStyle = WebMessageBodyStyle.Bare)]
Stream GetImage(String id, String format);
Implementation:
public Stream GetImage(String id, String format)
{
// stuff, stuff, stuff
using (Stream original = GetImageStream())
{
Stream result = CreateThumbnailStream(original, width, height);
result.Seek(0, SeekOrigin.Begin);
return result;
}
}
private Stream GetImageStream()
{
Bitmap copy = new Bitmap(Resource.SomePicture);
Stream result = new MemoryStream();
image.Save(result, ImageFormat.Png);
return result;
}
private Stream CreateThumbnailStream(Image image, Int32 width, Int32 height)
{
Image image = Image.FromStream(stream);
Image result = new Bitmap(width, height, PixelFormat.Format32bppArgb);
// shrinking routine skipped for brevity
return result;
}
So far, I've tried this:
removing all the 'usings' -> no effect (but probable memory leak)
wrapping the MemoryStream in a BufferedStream -> nope
removing Seek() -> no image (as expected)
What I'm I doing wrong? It worked on the different projects (not Azure though). Is the .NET 4.0 vs 4.5 compatibility the culprit?
I have a simple WCF service that exposes a REST endpoint, and fetches files from a BLOB container. The service returns the file as a stream. i stumbled this post about closing the stream after the response has been made :
http://devdump.wordpress.com/2008/12/07/disposing-return-values/
This is my code:
public class FileService
{
[OperationContract]
[WebGet(UriTemplate = "{*url}")]
public Stream ServeHttpRequest(string url)
{
var fileDir = Path.GetDirectoryName(url);
var fileName = Path.GetFileName(url);
var blobName = Path.Combine(fileDir, fileName);
return getBlob(blobName);
}
private Stream getBlob(string blobName)
{
var account = CloudStorageAccount.FromConfigurationSetting("ConnectingString");
var client = account.CreateCloudBlobClient();
var container = client.GetContainerReference("data");
var blob = container.GetBlobReference(blobName);
MemoryStream ms = new MemoryStream();
blob.DownloadToStream(ms);
ms.Seek(0, SeekOrigin.Begin);
return ms;
}
}
So I have two question :
Should I follow the pattern mentioned in the post ?
If I change my return type to Byte[], what are Cons/Pros ?
( My client is Silverlight 4.0, just in case it has any effect )
I'd consider changing your return type to byte[]. It's tidier.
Stream implements IDisposable, so in theory the consumer of your method will need to call your code in a using block:
using (var receivedStream = new FileService().ServeHttpRequest(someUrl))
{
// do something with the stream
}
If your client definitely needs access to something that Stream provides, then by all means go ahead and return that, but by returning a byte[] you keep control of any unmanaged resources that are hidden under the covers.
OperationBehaviorAttribute.AutoDisposeParameters is set to TRUE by default which calls dispose on all the inputs/outputs that are disposable. So everything just works.
This link :
http://devdump.wordpress.com/2008/12/07/disposing-return-values/
explains how to manually control the process.
I'm using WCF and I am trying to resume my upload with next code on the server app:
class DataUploader : IDataUploader
{
public void Upload(UploadMessage msg)
{
int speed = msg.AvgSpeed * 1024; // convert to KB
Stream stream= msg.DataStream;
string name = msg.VirtualPath;
int seekPoint; // this is get reading the partial uploaded file
using (FileStream fs = new FileStream(#"C:\savedfile.dat, FileMode.Append))
{
int bufferSize = 4 * 1024; // 4KB buffer
byte[] buffer = new byte[bufferSize];
int bytes;
while ((bytes = stream.Read(buffer, startPoint, bufferSize)) > 0)
{
fs.Write(buffer, 0, bytes);
fs.Flush();
}
stream.Close();
fs.Close();
}
}
}
I'm trying to begin to read the stream from a specified point (startPoint) cause the first bytes have already been uploaded. So I could append only remaining bytes to the file partially uploaded. By this way i get an error with the buffersize and can't use seeking because a method not supported exception so I think maybe this approach is not right. Help!!
My service contract:
[ServiceContract]
interface IDataUploader
{
[OperationContract]
void Upload(UploadMessage msg);
}
My message contract:
[MessageContract]
public class UploadMessage
{
[MessageHeader(MustUnderstand = true)]
public string VirtualPath { get; set; }
[MessageHeader(MustUnderstand = true)]
public int AvgSpeed { get; set; }
[MessageBodyMember(Order = 1)]
public Stream DataStream { get; set; }
}
It seems like you are using a standard soap message rather than the streaming binding. Check out the this link
If you don't want to use WCF's streaming api, which is proprietary to WCF, I would considering creating a 'chunking' method from the client if the client is uploading the file. Similar to how FTP can resume, I would query the server to see the current offset, send up a block or set of blocks, write them to my persistance (memory, db, file, etc), and then continue with multiple calls from the client sending smaller blocks (be careful of serialization as that can introduce unnecessary delays). This technique be something you want to investigate since it sounds like the client is 'streaming' to the server.
Btw, you may want to look at the following article to determine if your use of MessageContract is appropriate, as opposed to a DataContract.
http://blogs.msdn.com/b/drnick/archive/2007/07/25/data-contract-and-message-contract.aspx
If you want resume functionality you cannot do it this way. Your client must send the file in chunks and it must maintain the id of last successfully updated chunk. The service must process chunks and append them to storage.
If the most basic implementation it means that your client must divide file into chunks of well known size and call the upload operation for each chunk. The message must also contains the chunk Id and probably also chunk size (or something identifying the last chunk). This can be also combined with reliable session to allow automatic resend of lost chunks and to enforce in order delivery.
There is also example of channel implementation which does chunking internally.
I'm currently developing a WCF RESTful service. Within the validation of the POST data, I am throwing exceptions if the request XML does not conform to our business rules.
The goal is to send an e-mail to the appropriate staff if a request comes in that considered invalid. But, along with the incoming request headers, method and URI, I'd like to also send the XML that was posted.
I have not been able to find a way to access this data. Is WCF actually destroying the request body/data before I have a chance to access it or am I missing something?
Your help is appreciated as I'm confused as to why I can't access the request data.
This unfortunately isn't supported- we had a similar need, and did it by calling internal members with reflection. We just use it in an error handler (so we can dump the raw request), but it works OK. I wouldn't recommend it for a system you don't own and operate though (eg, don't ship this code to a customer), since it can change at any time with a service pack or whatever.
public static string GetRequestBody()
{
OperationContext oc = OperationContext.Current;
if (oc == null)
throw new Exception("No ambient OperationContext.");
MessageEncoder encoder = oc.IncomingMessageProperties.Encoder;
string contentType = encoder.ContentType;
Match match = re.Match(contentType);
if (!match.Success)
throw new Exception("Failed to extract character set from request content type: " + contentType);
string characterSet = match.Groups[1].Value;
object bufferedMessage = operationContextType.InvokeMember("request",
BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.GetField,
null, oc, null);
//TypeUtility.AssertType(bufferedMessageType, bufferedMessage);
object messageData = bufferedMessageType.InvokeMember("MessageData",
BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.GetProperty,
null, bufferedMessage, null);
//TypeUtility.AssertType(jsonBufferedMessageDataType, messageData);
object buffer = jsonBufferedMessageDataType.InvokeMember("Buffer",
BindingFlags.Instance | BindingFlags.Public | BindingFlags.GetProperty,
null, messageData, null);
ArraySegment<byte> arrayBuffer = (ArraySegment<byte>)buffer;
Encoding encoding = Encoding.GetEncoding(characterSet);
string requestMessage = encoding.GetString(arrayBuffer.Array, arrayBuffer.Offset, arrayBuffer.Count);
return requestMessage;
}
So, if you declare your contract something like:
[WebInvoke(Method = "POST", UriTemplate = "create", ResponseFormat=WebMessageFormat.Json)]
int CreateItem(Stream streamOfData);
(you can use XML instead)
The streamOfData should be the body of an HTTP POST. You can deserialize it using something like:
StreamReader reader = new StreamReader(streamId);
String res = reader.ReadToEnd();
NameValueCollection coll = HttpUtility.ParseQueryString(res);
It's working like that for us, at least. You may want to use a different approach to get the string into an XMLDocument or something. This works for our JSON posts. Might not be the most elegant solution, but it is working.
I hope this helps.
Glenn
Try this,
OperationContext.Current.RequestContext.RequestMessage
Here's how you do it without reflection:
using (var reader = OperationContext.Current.RequestContext.RequestMessage.GetReaderAtBodyContents ()) {
if (reader.Read ())
return new string (Encoding.ASCII.GetChars (reader.ReadContentAsBase64 ()));
return result;
}
}
If the reader is a HttpStreamXmlDictionaryReader (as it was in my case), the class's implementation of the method ReadContentAsBase64(byte[] buffer, int index, int count) simply passes these parameters to the Stream.Read method.
Once I have the byte[] I convert the bytes to a string via ASCII encoding. For a proper implementation, you could use the content type & encoding from the message's headers to do per HTTP spec.
You could arrest the HttpApplication.Request.InputStream in a custom HttpModule of the WCF Service, read the stream and again set its position to 0 in the custom HttpModule's event handler. Then store it in session and access it further in the actual OperationContract.
For example:
public class CustomModule : IHttpModule
{
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.AcquireRequestState +=context_AcquireRequestState;
}
void context_AcquireRequestState(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
Stream str = application.Request.InputStream;
StreamReader sr = new StreamReader(str);
string req = sr.ReadToEnd();
str.Position = 0;
application.Session["CurrentRequest"] = req;
}
}