I've been attempting to talk to a JSON API over HTTP using AFNetworking 2.0. The examples I found recommended the use of AFHTTPRequestOperationManager, so I implemented the following pseudocode:
manager = [[AFHTTPRequestOperationManager alloc] initWithBaseURL:[NSURL URLWithString:#"http://test-api.localdev/"]];
manager.requestSerializer = [AFJSONRequestSerializer serializer];
manager.responseSerializer = [AFJSONResponseSerializer serializer];
params = #{
#"username": #"Drarok",
#"token": #"1234-abcd"
};
[manager GET:#"transactions" parameters:params success:[…] failure:[…]];
Unfortunately, it appears that the AFJSONRequestSerializer does not (or perhaps can not) set the Content-Type, and I am unable to find a way to manually do so.
As such, the API rejects my request with an "HTTP 415 unsupported media type" error.
Other, similar questions are caused by the server response not being application/json, but this question is about the request headers.
This was caused by an incorrect API server asserting that all requests had a Content-Type: application/json header. AFNetworking will correctly avoid setting that header for HEAD, GET, or DELETE requests.
Related
I'm testing my application with Postman and while testing I've added multiple headers:
These headers I recieve in my API and I'm able to only debug my custom headers "loggedInUser" and "AuthorisationKey". I'm doing this with the following code:
loggedInUser = int.Parse(this.ActionContext.Request.Headers.GetValues("loggedInUser").First());
providedAuthKey = this.ActionContext.Request.Headers.GetValues("AuthorisationKey").First();
However I cant find the header "Content-Type" in my ActionContext, I've tried the following:
var requestedDatatype = this.ActionContext.Request.Headers.GetValues("Content-Type").First();
var requestedDatatype = this.Request.Content.Headers.ContentType;
Does anyone know how to do this?
Thanks in advance!
Authorization can handle it, check this out man https://learning.getpostman.com/docs/postman/sending_api_requests/authorization/
I have a wcf restful service that I need to get working in Chrome. I've read around and added all sorts of headers, etc but nothing is working. The POST works fine in IE, but when I get to Chrome, I get a 405 error on the OPTIONS request telling me that the method is not allowed. I've read where some people have added stuff to their global.asax file, but really don't feel like that should be necessary. I don't even have a global asax file and creating one just for the sole purpose of getting to work in chrome for development only seems crazy.
I'm using Aurelia's HTTP-Client library which uses just a simple XMLHttpRequest. Here's how it's configured:
this.Client = new HttpClient()
.configure(x => {
x.withBaseUrl("http://localhost/MyServices/MyService.svc/")
});
And I'm making the call like so:
this.Client.post("PostData/" + name,
{
version: 1
})
.then(resp => {
console.log(resp);
})
Here are the headers that I have added in my WCF Restful service WebConfig:
<add name="Access-Control-Allow-Origin" value="*" />
<!-- Not sure if these even do anything -->
<add name="Access-Control-Allow-Headers" value="Content-Type, Accept, X-Requested-With" />
<add name="Access-Control-Allow-Methods" value="OPTIONS, GET, POST" />
Then in my service itself:
[OperationContract]
[WebInvoke(Method = "POST", UriTemplate = "/PostData/{name}", RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped)]
Data myData(byte id, string name);
Like I said above, it works fine in IE, but chrome gives me a preflight error. Here's a snippet of the fiddler response:
HTTP/1.1 405 Method Not Allowed
Entity
Content-Length: 1565
Content-Type: text/html; charset=UTF-8
Security
Access-Control-Allow-Headers: Content-Type, Accept, X-Requested-With
Access-Control-Allow-Methods: OPTIONS, GET, POST
Access-Control-Allow-Origin: *
Allow: POST
I also find that if I add x.withHeader("Content-Type", "application/json; charset=utf-8") to my Http-Client configuration, Chrome doesn't even do a GET request. It throws the error.
To sum it all up, I can do GET requests but not POST requests in Chrome. How do I fix it?
I am using HTML5 fetch API.
var request = new Request('https://davidwalsh.name/demo/arsenal.json');
fetch(request).then(function(response) {
// Convert to JSON
return response.json();
}).then(function(j) {
// Yay, `j` is a JavaScript object
console.log(JSON.stringify(j));
}).catch(function(error) {
console.log('Request failed', error)
});
I am able to use normal json but unable to fetch the data of above api url.
It throws error:
Fetch API cannot load https://davidwalsh.name/demo/arsenal.json. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Like epascarello said, the server that hosts the resource needs to have CORS enabled. What you can do on the client side (and probably what you are thinking of) is set the mode of fetch to CORS (although this is the default setting I believe):
fetch(request, {mode: 'cors'});
However this still requires the server to enable CORS as well, and allow your domain to request the resource.
Check out the CORS documentation, and this awesome Udacity video explaining the Same Origin Policy.
You can also use no-cors mode on the client side, but this will just give you an opaque response (you can't read the body, but the response can still be cached by a service worker or consumed by some API's, like <img>):
fetch(request, {mode: 'no-cors'})
.then(function(response) {
console.log(response);
}).catch(function(error) {
console.log('Request failed', error)
});
This worked for me :
npm install -g local-cors-proxy
API endpoint that we want to request that has CORS issues:
https://www.yourdomain.com/test/list
Start Proxy:
lcp --proxyUrl https://www.yourdomain.com
Proxy Active
Proxy Url: http://www.yourdomain.com:28080
Proxy Partial: proxy
PORT: 8010
Then in your client code, new API endpoint:
http://localhost:8010/proxy/test/list
End result will be a request to https://www.yourdomain.ie/test/list without the CORS issues!
Solution to resolve issue in Local env's
I had my front-end code running in http://localhost:3000 and my API(Backend code) running at http://localhost:5000
Was using fetch API to call the API. Initially, it was throwing "cors" error.
Then added this below code in my Backend API code, allowing origin and header from anywhere.
let allowCrossDomain = function(req, res, next) {
res.header('Access-Control-Allow-Origin', "*");
res.header('Access-Control-Allow-Headers', "*");
next();
}
app.use(allowCrossDomain);
However you must restrict origins in case of other environments like stage, prod.
Strictly NO for higher environments.
I know this is an older post, but I found what worked for me to fix this error was using the IP address of my server instead of using the domain name within my fetch request.
So for example:
#(original) var request = new Request('https://davidwalsh.name/demo/arsenal.json');
#use IP instead
var request = new Request('https://0.0.0.0/demo/arsenal.json');
fetch(request).then(function(response) {
// Convert to JSON
return response.json();
}).then(function(j) {
// Yay, `j` is a JavaScript object
console.log(JSON.stringify(j));
}).catch(function(error) {
console.log('Request failed', error)
});
You need to set cors header on server side where you are requesting data from.
For example if your backend server is in Ruby on rails, use following code before sending back response. Same headers should be set for any backend server.
headers['Access-Control-Allow-Origin'] = '*'
headers['Access-Control-Allow-Methods'] = 'POST, PUT, DELETE, GET, OPTIONS'
headers['Access-Control-Request-Method'] = '*'
headers['Access-Control-Allow-Headers'] = 'Origin, X-Requested-With, Content-Type, Accept, Authorization'
If you are use nginx try this
#Control-Allow-Origin access
# Authorization headers aren't passed in CORS preflight (OPTIONS) calls. Always return a 200 for options.
add_header Access-Control-Allow-Credentials "true" always;
add_header Access-Control-Allow-Origin "https://URL-WHERE-ORIGIN-FROM-HERE " always;
add_header Access-Control-Allow-Methods "GET,OPTIONS" always;
add_header Access-Control-Allow-Headers "x-csrf-token,authorization,content-type,accept,origin,x-requested-with,access-control-allow-origin" always;
if ($request_method = OPTIONS ) {
return 200;
}
Look at https://expressjs.com/en/resources/middleware/cors.html
You have to use cors.
Install:
$ npm install cors
const cors = require('cors');
app.use(cors());
You have to put this code in your node server.
I'm trying to use AFNetworking 2.0 to perform my network requests but I'm running into some odd behavior. I've subclassed AFHTTPSessionManager as suggested in the documentation and provided a class method that returns a singleton object that has the base url set as well as sets my auth header.
+ (id)sharedInstance {
static dispatch_once_t once;
static MyHTTPClient *sharedInstance;
dispatch_once(&once, ^{
sharedInstance = [[self alloc] initWithBaseURL: NSURLURLWithString:kPlatformAPIBaseURL]];
});
//Uncommenting this line makes the error go away
//sharedInstance.responseSerializer = [AFJSONResponseSerializer serializer];
//get latest session id everytime someone gets an instance of the client
sharedInstance.sessionId = [MySessionManager getSessionId];
return sharedInstance;
}
- (instancetype)initWithBaseURL:(NSURL *)url {
self = [super initWithBaseURL:url];
if(self) {
self.sessionId = [FSSessionManager getSessionId];
self.serializer = [AFHTTPRequestSerializer serializer];
[_serializer setValue:_sessionId forHTTPHeaderField:kAuthorizationHeader];
[_serializer setValue:#"application/json" forHTTPHeaderField:kAcceptHeader];
self.requestSerializer = _serializer;
}
return self;
}
- (void)setSessionId:(NSString *)sessionId {
_sessionId = sessionId;
[self.serializer setValue:_sessionId forHTTPHeaderField:kAuthorizationHeader];
}
My app uses this to make a POST request to authenticate my user. That works great. I then make a GET request to retrieve a list of objects. Also works great. I then make the same GET request and I get back a network error Error Domain=AFNetworkingErrorDomain Code=-1016 "Request failed: unacceptable content-type: application/json" It's the exact same GET request but it fails on the second call. When I uncomment the sharedInstance.responseSerializer line so I create a new instance of the response serializer each time I get a reference to my shared instance then I don't get this error anymore.
Can a responseSerializer not be used multiple times safely? It feels like some sort of state is hanging around across requests. What's the correct way to set this up?
A response serializer can be used multiple times safely. Based on the error message you posted, "unacceptable content-type: application/json ", it appears you're setting responseSerializer to something else elsewhere in your code. JSON will serialize properly as long as it's set to [AFJSONResponseSerializer serializer].
I'm using AFNetworking and like it very much.
I need to get JSON data from my server and it's OK, it works perfectly.
I added the setDownloadProgressBlock but I think it can't work with JSON download: maybe it's not possible to get the estimated amount of bytes to download.
My code:
NSMutableURLRequest *request = [[VinocelaHTTPClient sharedClient] requestWithMethod:#"GET" path:#"ws/webapp/services/pull" parameters:nil];
AFJSONRequestOperation *operation = [AFJSONRequestOperation JSONRequestOperationWithRequest:request
success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON)
{
}
} failure:^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error, id JSON)
{
}];
[operation setDownloadProgressBlock:^(NSInteger bytesWritten, NSInteger totalBytesWritten, NSInteger totalBytesExpectedToWrite) {
NSLog(#"Get %d of %d bytes", totalBytesWritten, totalBytesExpectedToWrite);
}];
[operation start];
And my result :
Get 27129 of -1 bytes
Get 127481 of -1 bytes
Get 176699 of -1 bytes
So, I think AFNetworking can't estimate the real size to download when downloading JSON data contrary to a zip file or an image ?
From perusing the source, it seems that the progress callback is just passed the expectedContentLength property of the cached, internal NSHTTPURLResponse object. So, if for some reason your server isn't correctly sending the Content-Length header, and/or is doing chunked transfer encoding, that value is unknown, and the value NSURLResponseUnknownLength is returned (which happens to be defined as -1).
Try inspecting the headers returned by an HTTP request outside the context of your app. If you get a Content-Length header with a sane value, the problem likely lies in AFNetworking itself. If it is absent, the problem lies with the server. I've never seen an HTTP server send a JSON response using chunked transfer encoding (most of the time the content size should be relatively small and known at the time the headers are sent), but it's within spec for it to do so.