I have an ASP.NET web application that's returning a multi-part response containing a JSON-encoded object, plus a bunch of binary files. (For the code that produces this, see https://stackoverflow.com/a/12334553/98422 - that question also gives a bit of background).
The HTTP response data looks like this:
--b621907a-a740-44f4-b495-a91a078b90ef
Content-Type: application/json; charset=utf-8
[1,2]
--b621907a-a740-44f4-b495-a91a078b90ef
Content-Type: image/jpeg
<image file content>
--b621907a-a740-44f4-b495-a91a078b90ef
Content-Type: text/plain
<text file content>
--b621907a-a740-44f4-b495-a91a078b90ef--
So, I now want to consume the response at the client end. My client is a C# application.
How can I do this? I assume that there must be some framework support for it, but I'm not sure where to start looking.
It probably isn't relevant, but I'm using RestSharp for the bulk of my interaction with the web server. So far as I can tell, RestSharp would not be able to process this response (which is fair enough - it's not very RESTy).
What options do I have?
Related
Why .Net WebApi don't detect the request contentType automatically and do auto-binding?
If I make a request without informing the contentType a HTTP 500 error occour:
No MediaTypeFormatter is available to read an object of type 'ExampleObject' from content with media type ''undefined''.
why not try to detect the incoming data and bind automatically?
Another case:
This request with Content-Type: application/x-www-form-urlencoded send a JSON:
User-Agent: Fiddler
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Host: localhost:10329
Content-Length: 42
Request Body:
{"Name":"qq","Email":"ww","Message":"ee"}:
My Action don't detect the JSON request data automatically in object param:
public void Create(ExampleObject example) //example is null
{
{
Instead of letting the object null why they do not try to solve it?
Then, for the binding occurs I need to send with Content-Type: application/json.
It would be best if .Net WebAPI detects the type of request data and do a auto-binding? Why not in this way?
application/x-www-form-urlencoded means you will be sending data in the x-www-form-urlencoded standard. Sending data in another standard will not work.
Sounds like what you want to do is accept multiple formats from the server.
the way http works is that the client makes a request to the server for a resource and tells the server what content types it understands. This means that the client doesnt get a response it isnt able to decode, and the server knows which responses are more appropriate on the client. For example if you are a web-browser the most appropriate content type is text/html but if you get XML you can probably do something with that too. So you would make a request with the following:
accept: text/html, application/xml
this says you prefer html but also understand XML
In your example if your client wants application/x-www-form-urlencoded but can also deal with JSON then you should do the following when making a request
accept: application/x-www-form-urlencoded, application/json
For more details see the HTTP Spec on accept headers here http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
You may also want to create a new media type formatter so your server knows how to give clients application/x-www-form-urlencoded, take a look at this blog post for more info on how to do this http://www.strathweb.com/2012/04/rss-atom-mediatypeformatter-for-asp-net-webapi/
I'm troubleshooting an integration between an external service which posts multipart/form-data data to a Controller in MVC3.
On the production server I've captured erroneous request using HttpRequest.SaveAs to a file.
Is there any tool I can use to "replay" the request on my localhost so I can debug with Visual Studio?
(I've been trying with fiddler but I can't get it working right. If a dump a local request from a simple form with POST my controller recieves the files correctly. If i dump the same request and copy paste it into fiddler as raw and send the files are missing so there's something wrong.)
Since there's a built-in function to dump the request I'm thinking it might be some official way to resend the request as well. Is there a way to achieve this?
I have used NCAT command line tool to replay requests captured by SaveAs method.
Command looks like this:
NCAT localhost 80 < CapFileName
you can find it in NMAP library
See my blog for more information.
I got it working in fiddler if I do exactly this in the composer:
Open the dumpfile in notepad
Choose Parsed
Only enter the Content-Type as headers (and let fiddler add the others even if they were the same)
Paste the body of the request in request body from notepad
POST: http://localhost/Controller/Action
Request headers:
Content-Type: multipart/form-data; boundary=fJP-UWKXo6xvqX7niGR0StXXFQwdKhHc9quF
Request body:
--fJP-UWKXo6xvqX7niGR0StXXFQwdKhHc9quF
Content-Disposition: form-data; name="mmsimage"; filename="IMG_0959.jpg"
Content-Type: image/jpeg; name=IMG_0959.jpg; charset=ISO-8859-1
Content-Transfer-Encoding: binary
<the encoded file goes here as jibberish>
--fJP-UWKXo6xvqX7niGR0StXXFQwdKhHc9quF
Content-Disposition: form-data; name="somefield"
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
value of somefield
--fJP-UWKXo6xvqX7niGR0StXXFQwdKhHc9quF--
My .NET ASMX webservice is accepting requests from a client I don't have direct control over. It's sending a request that looks like this:
POST /Service.asmx HTTP/1.1
Connection: Keep-Alive
Pragma: no-cache
Content-Length: 1382
Content-Type: text/xml
Accept: text/xml
Host: localhost
User-Agent: Borland SOAP 1.1
SOAPAction: "http://domain.com/InsertRecords"
<?xml version="1.0"?>
<SOAP-ENV:Envelope... <v>ÄLMÅ BÄCK</v></SOAP-ENV:Envelope>
In my WebMethod, the string ÄLMÅ BÄCK gets munged to ??LM?? B??CK -- typical encoding mess-up.
In my testing I've found that if I simply tweak the content-type header, all is well:
Content-Type: text/xml; charset=utf-8
Why is .NET choosing an encoding other than utf-8 when it's unspecified, and is there any way I can coerce this ASMX to use UTF-8 encoding?
The following code run before the web service handler is invoked resulted in the HTTP Request correctly decoded:
if (HttpContext.Current.Request.ContentType == "text/xml") {
HttpContext.Current.Request.ContentType = "text/xml; charset=UTF-8";
}
This feels a bit hacky, but I believe it'll work well for my circumstances. I'm still very interested in some background information on why this was an issue at all, and if there's a better way to pull this off (besides getting the client to be more explicit about the encoding).
IIS 7.5 has configuration options to help with this. (I don't know if earlier versions support this.) I had a similar issue where I have a web application that receives requests from a system that uses the upper 5 characters of the extended ASCII character set as meaningful delimiters. These were getting munged by the decoding that IIS was applying to incoming requests. I found some IIS config options to fix this issue.
First, in IIS Manager, select your website and open the .NET Globalization settings:
There are settings for the expected encodings for File, Requests, Response Headers, and Responses. There are dozens of encoding options to choose from:
This worked perfectly for my scenario because this particular site only received requests from a program that I wrote, so I controlled both ends. With an unknown audience, you're just hoping your users encode their requests appropriately. (But then, that's true even if you use the default encodings...)
I have Spring MVC + JAXB web service and Flex client. I am getting HTTP 406 error when using RestFUL API. Here is request and response headers on image:
Can you help me for solving this problem?
This problem comes when the data returned from the server is not in the format that is excepted by the browser. Also this can be caused by any one of the following:
Accept: The MIME types accepted by the browser. For example, HTML files, GIF files etc.
Accept-Charset: The character sets accepted by the client, e.g. utf-8, iso-8859-1 etc.
Accept-Encoding: The data encoding accepted by the client e.g. the file formats it understands, e.g. gzip.
Accept-Language: The natural languages (English, German etc.) accepted by the client.
Check what the server is returning and fix the problem!
I have a web performance test which contains a request whose response is greater than 5MB, and the Extract Hidden Fields rule fails to find (necessary and required!) hidden fields in the response.
Response header contains
HTTP/1.1 200 OK
Transfer-Encoding : chunked
Vary : Accept-Encoding, User-Agent
Cache-Control : private
Content-Type : text/plain; charset=utf-8
Date : Sat, 19 Feb 2011 15:24:38 GMT
Server : Microsoft-IIS/6.0
X-AspNet-Version : 2.0.50727
X-Powered-By : ASP.NET
Other than that and the response size, there is nothing remarkable about this scenario. In fact, this same test succeeds when a smaller data set is used.
I suspect the Web Performance Test framework is having issues parsing the "chunked" encoding or sheer volume of data.
Ahem, how can I obtain these required hidden fields from my response? Any hints or pointers would be much appreciated. ie resolutions, work arounds, converting auto-extraction to manual, etc.
Cheers!
Alright, so after much fussing around, found this neat little article, which indicates web test recorder captures ONLY first 1.5MB of data returned from request. In summary, the solution is to convert web test to a coded web test, and increase the test's ResponseBodyCaptureLimit to desired size.