I've created a WCF REST service and initially used .Net Framework version 4. The service has two methods, one returns a plain string with the service status. The second allows a file to be uploaded. Both methods were working fine.
I was asked to see if the project could be moved back to only depend on .Net Framework 3.5 instead of version 4. I changed some references, and it built ok, and when I use the existing C++ client I can use the GetStatus method fine. However, now when a file gets uploaded, the client sees successful return codes to all methods, but, when I set a breakpoint at the start of WCF service's FileUpload method, it never gets executed. The file doesn't gets uploaded, it just disappears into the ether.
[ServiceContract]
internal interface IMyWebService
{
[OperationContract]
[WebGet(UriTemplate = "/Status", BodyStyle=WebMessageBodyStyle.Bare)]
Stream GetStatus();
[OperationContract]
[WebInvoke(Method = "POST", UriTemplate = "/FileUpload/{fileName}")]
Stream FileUpload(string fileName, Stream fileStream);
}
I've tried to use the WFetch tool as an alternative client. When I call the FileUpload method, I get this log:
started....WWWConnect::Close("localhost","80")\nclosed source port: 15800\r\n
WWWConnect::Connect("localhost","80")\nIP = "[::1]:80"\nsource port: 15866\r\n
REQUEST: **************\nPOST http://myMachine/MyService/FileUpload/hello.txt HTTP/1.1\r\n
Host: localhost\r\n
Accept: */*\r\n
Content-Length:11\r\n
\r\n
hello thereRESPONSE: **************\nHTTP/1.1 415 Missing Content Type\r\n
Content-Length: 0\r\n
Server: Microsoft-HTTPAPI/2.0\r\n
Date: Thu, 22 Sep 2011 13:26:09 GMT\r\n
\r\n
finished.
Could anybody give me any pointers for how I can diagnose this issue? I'm having trouble seeing where to start because no breakpoints get hit, and there are no error codes to investigate.
The WCF service must be doing something, because if I stop it, the client then fails to upload files, I just can't understand why execution never gets to the method that implements the POST operation.
Hmm, when using WFetch, even if I misspell the name of the method, it still seems to succeed with no error.
Thanks.
I'd start troubleshooting with the original 4.0 version of the service and a C# WCF-based test client to verify the service code will actually upload a file successfully. You could use the code in this Technet article for developing the test client.
Next, use your C++ client against the 4.0 service to verify your client will successfully send a file. Lastly, set the service back to 3.5 and see if it still works. To log messages the service is receiving for troubleshooting, look at this MSDN post to configure the built-WCF message logging capability.
Related
Using WSO2 API Manager 1.3.1. Trying to use the API Manager to proxy to a REST service. I have set up the service in API Mgr and can successfully post and get responses, typically json, though some are text.
However, when I try to GET a resource that returns binary content (a zip "file", content-type:application/octet-stream), the API Manager does not seem to respond and I can see an error in the console window (i'm running wso2server.bat in console):
[2013-07-03 11:52:05,048] WARN - SourceHandler Connection time out
while writing the response: 173.21.1.22:1268->173.21.1.22:8280
I have an HTTPModule on my internal service and it seems to be responding with the appropriate content (I can see the GET and response data logged). I can also call to the internal service directly and get a response, so that end of things seems OK. But going through the API Manager seems to fail.
I found information on enabling other content-types:
WSO2 API Manager - Publishing API with non-XML response
http://wso2.com/library/articles/binary-relay-efficient-way-pass-both-xml-non-xml-content-through-apache-synapse
Using that information I tried to enable the application/octet-stream for messageFormatter and messageBuilder using the binary relay and it did not help (or seem to make a difference). I have even disabled all other content-types and use the binary relay for all content-types and it does not help.
Currently, I'm running with just the following in both axis2.xml and axis2_client.xml (in their appropriate sections):
<messageBuilder contentType=".*" class="org.wso2.carbon.relay.BinaryRelayBuilder"/
<messageFormatter contentType=".*" class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
I still get my json and text responses, but WSO2 times out getting the zip content. I saw the JIRA referenced in axis2.xml about enabling the ".*" relay, but as the other requests seem to work, I'm not sure it's an issue for me. I did try adding
'format="rest"' to the API definition, but it seemed to break all operations even the ones that worked prior so I've pulled it back out.
Any ideas on what is happening or how to dig in and debug this will help. Thanks!
After working with this for much too long, it turns out that my WSO2 configuration was correct, using the Message Relay and BinaryRelayBuilder, etc. While my REST service could reply immediately, I was setting a HTTP header that I assume WSO2 does not like, because when i removed it WSO2 would reply at an expected rate (instantly).
I was setting the header:
Transfer-Encoding: binary
When I removed that header from my service reply, then WSO2 operated as expected. I don't know if that's a "bug" in WSO2 or if I was implementing incorrectly, but I do have what seems like a "workaround" by omitting that header from my service response.
I am running a very simple Web application (Asp.Net MVC3) on Win 7 IIS.
I have a very simple HTTP GET API which returns hello world.
Calling:
http://localhost/helloworld
Returns:
Hello World!
This works perfectly over a browser.
But when I write an app which tries to pull this URL using a webclient, I get the following error:
{"Unable to read data from the transport connection: The connection was closed."}
My Code is as follows
WebClient web = new WebClient();
var response = web.DownloadString("http://localhost/helloworld");
My IIS Settings are as follows
What should I be looking at? I have been at this for hours and I have run out of options to try! Any help will be really appreciated!
Thanks.
I suspect it's because WebClient does not send some of the HTTP headers:
A WebClient instance does not send optional HTTP headers by default. If your request requires an optional header, you must add the header to the Headers collection. For example, to retain queries in the response, you must add a user-agent header. Also, servers may return 500 (Internal Server Error) if the user agent header is missing. http://msdn.microsoft.com/en-us/library/system.net.webclient(v=vs.80).aspx
Try using HttpWebRequest instead. http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.aspx
I finally figured out what the issue was and instead of it being an IIS specific issue - which I was leaning towards, it turned out to be an issue with the code that I wrote.
Adding details here incase someone else runs into a similar problem.
I had the following method in my code which I was using to send the response of the request as a JSON object.
private void sendJsonResult(string result) {
Response.StatusCode = 200;
Response.Headers.Add("Content-Type", "application/json; charset=utf-8");
Response.Flush();
Response.Write(result);
Response.End();
Response.Close(); // <-- This is the problem statement
}
On digging around a bit, I found out that we should not be doing a Response.Close().
A better explanation of this is here.
Once I removed that line, it started working perfectly - both in my consuming app as well as the web browser, etc.
If you will read the link above, you will clearly understand why we should not be using a Response.Close() - so I will not go into that description. Learnt a new thing today.
Scenario:
Web Service needed to calculate values and send results back as json. These calls are to be made cross-domain so I'm using jsonp. The problem I'm having occurs both on the same domain and cross-domain.
Problem:
I'm having an issue getting back json data from a WCF Service. While on my local machine it works fine, but when on the server the response from the service is cut short (if I run it through Visual Studio on the server though, it's fine).
The content length seems to be set as the length of my response before wrapping it in the jquery callback function (example data below).
Local: jQuery151017220264650085249_1309423933796({"d":"[\"Flat\",\"Terrace\",\"Semi\",\"Detached\",\"Bungalow\"]"});
Local: jQuery151017220264650085249_1309423933797({"d":"[\"New build\",\"2000 to 2010\",\"1990 to 2000\",\"1970 to 1990\",\"1950 to 1970\",\"Pre 1950\"]"});
Live: jQuery1510246237260361726_1309424024004({"d":"[\"Flat\",\"Terrace
Live: jQuery1510246237260361726_1309424024005({"d":"[\"New build\",\"2000 to 2010\",\"1990 to 2000\",\"1970 to
To wrap the json response with the callback function I had to use a httpmodule I found on the net.
The server uses IIS 7.5, locally i'm just using Visual Studio. (Some kind of IIS configuration?)
Right, hopefully I've provided enough information, if not let me know.
So if anyone has any idea how I could fix this issue it would be greatly appreciated.
Thanks
You don't need to use an HTTP Module to wrap the response in JSONP - this feature is available in WCF 4.0. You can set the property CrossDomainScriptAccessEnabled in WebHttpBinding, and if the request comes from a different domain (and it has a ?callback=FunctionName) parameter, the response will be wrapped in FunctionName(...).
I've got a WCF Service, which calls a webservice, running on my development IIS server (IIS 7). I've added it as a service reference to a C# Website Project and it adds fine.
However, when I try to call any of the service contracts, I get the following error:
The content type text/html
of the response message does not match
the content type of the binding
(text/xml; charset=utf-8). If using a
custom encoder, be sure that the
IsContentTypeSupported method is
implemented properly. The first 1024
bytes of the response were:
'Blocked Web
Page
thanks in advance
BB
The error message says it clearly: you're getting back an HTML page instead of your service response. Looking at the fragment of that page listed in the error message, you're probably not authroized to use that service.
Try to connect to the service URL in a browser - you should probably see a page explaining that you're not allowed to access the page. Most likely, this is a permissions issue.
You need to configure WCF Tracing and find out what's happening on the server side.
In our project, we are calling the .svc file directly from asp.net web page and I receive the error "The remoter server returned an error:(400) bad request.
Our project architecture is, we are using .svc file in our web application and the .cs file for the svc in writter in another class library project. From aspx, we are calling the WCF service directly without adding reference or anything. I cannot change the concept, because it is our standard. I'm able to add service reference and call those methods, but I wanted to call the method directly from .svc url.
I'm pissed off for 2 days and could not resolve the error. We are using HttpWebRequest to get the response from the service. Basically, the service will take Data Transfer Object(DTO) as input and returns the same(DTO) as output with only one value.
Check the following code:
HttpStatusCode statusCode = HttpHelper.PostXmlRequestValue(requestXMLInput,
string.Format("http://{0}/{1}/MySample.svc/webhttp/MyMethodName",
Request.ServerVariable["HTTP_HOST"], Request.ApplicationPath);
The same code works in one machine but not in the other. I have checked the configuration and everything is same, but still I receive the same error.
When I use the .svc url in my machine, it works, but gives a message "Method not allowed". When I checked the same url in the working machine, I got the same message.. I believe there is some simple thing I'm missing out. I couldn't find, as I'm new to WCF.
When using HttpWebRequest the "Method not allowed" error is for example that you are sending a Http GET, when the service expects a Http POST.
HttpWebRequest is a REST based configuration, this limits the complexity of the DTO's that you can send.