I'm trying to send a POST request with parameters and a body (via C# for Windows Phone). In order to send parameters, I need to use application/x-www-form-urlencoded for the Content-Type header.
Only problem is the server I'm communicating with expects me to have Content-Type set to something else (a custom value).
Basically for a link in the form of ip/path/file?param1=value1¶m2=value2, sent via POST with the POST body being JSON content, I need to set Content-Type to something custom, but still have the parameters sent.
Is there any conceivable way of doing this? I realize it's a bit of a paradox. Changing the server API to respond to other Content-Type headers is not possible.
Some headers can be set using API properties only.
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://www.androidlost.com/androidlost/greet");
request.ContentType = "text/x-gwt-rpc; charset=utf-8";
I found the answer shortly after posting the question. It seems that if I construct the URL string to include the actual parameters it works like a charm.
This is oppposed to the situation where I would add parameters problematically via HTTP Requests api.
Related
I have a GET API which returns an object of a particular class. I want to send additional information ( a number) without modifying the object in the response.
Following options came to my mind :
1) Using some header value and updating it and send the response(but I think that using headers would be a bad practice in this scenario).
2)Send a multipart response.
Thanks in advance!
If there is no way you can change the response and you need just simple data like numbers, it's OK to use HTTP headers in your response. You can see sample how to do paging using HTTP headers.
As usual, in .NET 4.5, I used a HttpClient to send a get request to restful service (a remote server)
However, this time, it returned error 415 - Unsupported Media Type.
I'm expecting the request header including Content-Type = application/json.
And I cannot find a way to set Content-Type correctly.
Anybody has experience for this case or any suggestion will be appreciated!
The code is as below and the httpResponseMessage.RequestMessage.Headers
Updated 1
As I researched, I cannot add a retricted header for Content-Type. Since this is 4.5 implementation. Is this correct?
Updated 2
I tried to add
request.Content.Headers.ContentType = new MediaTypeHeaderValue("application/json");
However it returned Cannot send a content-body with this verb-type
I am guessing that your server is not complaining about the invalid content type you requested but about the content type you sent with that request.
That you get
Cannot send a content-body with this verb-type
seems to hint that your tried to send a GET request. It is rather unusual (allthough technically the HTTP protocol allows this) that servers require a GET request with a body. So my best guess is that there is something wrong with the server.
I am adding multiple custom headers in my HttpResponse and on the next request from the browser for the page, I want to read those custom headers and determine if I need to send a 304 response to the browser.
I added the custom headers using Response.AddHeader but on the next request from the browser, the custom headers were not sent.
The browser did recieve the custom headers in the response stream but did not send them on the subsequent request.
I'm expecting the headers since I need to read them on the first request and not on post requests.
NOTE: I don't want to use cookies since I don't want to increase payload. I don't want to use sessions since I don't want to burden the server. My aim to decrease processing in the server as much as possible. As I've mentioned in my comment, I read about ETags and I'm hoping the technique that's used in ETags could be used for custom headers.
There are other ways of of passing information between requests. See this discussion.
You can also use session variables.
I have been trying to debug an issue communicating with a web service, and it led me to a question. I was wondering what the difference between WebClient.UploadValues and WebClient.UploadData was in C#. I found the answer to that here .NET WebClient.UploadValues vs WebClient.UploadData
The answer as essentially that UploadData submits content in the body of the request, where as UploadValues acts like submitting values from a form. I would have thought they were the same thing. When you submit content in the body of a post, it usually looks something like "key=value&key2=value2...". (when the content type is application/x-www-form-urlencoded)
I thought they were the same thing until I noticed something. Using UploadValues gives me a totally different result than UploadData. In the case of the service I am communicating with, using UploadValues succeeds and UploadData returns the error "Request format is invalid".
So what exactly is the difference between a form post data and the content in the body of a request? Are they actually different things? Does an http request contain a querystring, body, AND form data?
Thanks!
UPDATE Okay, so I know what my problem was and I think I know the answer to most of my question.
Upload Values submits the body with content type application/x-www-form-urlencoded. I am not entirely sure what content-type is used for UploadData by default, but you can set the header explicitly so it will take whatever you give it.
My original confusion arose when I was trying to do this by composing an HttpWebRequest and writing the content to the RequestStream. I was setting the Content Type too late. I guess it needs to be specified BEFORE writing to the Stream.
Form data is sent in the body of the request.
Okay, so I know what my problem was and I think I know the answer to most of my question.
Upload Values submits the body with content type application/x-www-form-urlencoded. I am not entirely sure what content-type is used for UploadData by default, but you can set the header explicitly so it will take whatever you give it.
My original confusion arose when I was trying to do this by composing an HttpWebRequest and writing the content to the RequestStream. I was setting the Content Type too late. I guess it needs to be specified BEFORE writing to the Stream.
Form data is sent in the body of the request.
I'm getting a 406 error when trying to use RestSharp to post a request to a third-party application. I'm new to REST, so I have to admit I didn't even know you could add headers. I tried adding these, but I'm still getting the same issue:
var client = new RestClient(myURL);
RestRequest request = new RestRequest("restAction", Method.POST);
request.AddHeader("Accept", "text/plain");
request.AddHeader("Content-Type", "text/plain");
request.AddParameter("parameter1", param1);
request.AddParameter("parameter2", param2);
var response = client.Execute(request);
From what I've read, this may be dealing with a header named "accept". Is that right?
Any idea what could be going on?
In general in HTTP, when a client makes a request to a server, it tells the server what kinds of formats it's prepared to understand (accept). This list of acceptable formats is what the Accept header is for. If the server can't respond using any of the media types in the Accept header, it will return a 406. Otherwise, it will indicate which media type it chose in the Content-Type header of the response. Putting "*/*" in the Accept header tells the server that the client can handle any response media type.
In my original comment to your question, I said that RestSharp looks like it's including "*" in the Accept header by default, but looking closer I see now that it's actually not. So, if you don't override the Accept header like you've done here, the default header value is "application/json","application/xml","text/json","text/x-json","text/javascript","text/xml", and it appears the server you're talking to doesn't speak any of these media types.
If the server you're working with doesn't speak json or xml, I don't think you can use RestSharp, unless you create your own deserializer. I'm not sure if you can do this from the public API or if you'd have to modify the source yourself and recompile it for you own needs.
Since you're still getting HTTP errors from the server, I would recommend taking RestSharp out of the equation for right now, and just speaking HTTP directly to the server until you actually get a correct response from the server. You can use a tool like Fiddler to make a HTTP requests directly. When you send the request (for now in the debugging stage), send an Accept header of "*/*" to get around the 406. Once you've figured out what media types the server can send back to you, you should change this back to being a media type you know you can read and you know the server can send.
It sounds like the main issue here is really just not knowing the protocol of the server. If there's any documentation on the service you're talking to, I would read that very carefully to figure out what media types it's prepared to respond with and how to craft the URLs that it expects.