I'm building my latest app using nodeJS and need to be able to upload multiple files. I have chosen to use Uploadify flash based file uploader.
Unfortunately the 'scriptData' vars don't seem to be being sent. Usual method of retrieval of POST vars in node looks like var postDataValue = req.body.postDataKey; but with Uploadify the req.body object is empty.
Hope someone can help with this.
I had to send the parameters via query string in the end. Must be something to do with NodeJS.
It's not Node.js. req.body is not part of node. It's built into BodyParser and provided by Connect. Mainly used in Express.
See http://senchalabs.github.com/connect/middleware-bodyParser.html
If you don't use it, the req.body object should be empty.
Related
I'm new to MobileFirst development. I need to download a zip file from one of the adapters. I am able to do this when invoking REST API call eg using Postman. But I'm not sure how to handle this when using MFS sdk:
Here's my code to access the adapter:
var resourceRequest = new WLResourceRequest(url,
WLResourceRequest.GET
);
const resp = await resourceRequest.send()
I log the response and it's showing special characters in the responseText.
Is there a way to handle the binary response?
Thank you in advance for your help!
For any binary content, you will have to convert the content to Base 64 in your adapter and revert it back to binary in your app.
This is because the WLResourceRequest APIs are designed for handling text based data.
If your binary content is rather large, then it is best to host the file somewhere and return the link to the file from your adapter.
I am trying to upload files to a webservice using the Upload scalar in apollo-server-express. I can upload small files(10s of kbs) to the webservice but am having trouble getting larger files to send.
I did some searching and found that I can change the body size limit using the body-parser package, along with the bodyParserConfig option set in middleware. I've tried implementing this, as well as implementing it in the express app itself, however neither seem to be working.
bodyParserConfig example snippet
const bodyParserConfig = bodyParser.urlencoded({limit: '50mb', extended: 'true', parameterLimit: 10000});
server.applyMiddleware({ app, path: process.env.GRAPHQL_ENDPOINT, bodyParserConfig});
I'm not sure if I need to use the json method as inside the apollo service it calls json(config) so I tried this and it also didnt work.
const bodyParserConfig = {limit: '50mb'};
server.applyMiddleware({ app, path: process.env.GRAPHQL_ENDPOINT, bodyParserConfig});
express example snippit
app.use(bodyParser.json({limit: '50mb'}))
Trying out both of these options, as well as options from Error: request entity too large don't seem to work for me. The webservice(Nifi HTTPHandleRequest) tells me it failed to receive content. Most examples of solutions(like the one above) have been specifically for express and not apollo-express-server so I'm not sure if theres a different approach I need to take. The apollo-server documents state to use the bodyParserConfig option, so I'm wondering if I'm not formatting the config correctly.
Is there something simple I'm doing incorrectly? Also how can I view what the limit is? It's hard to debug and see if the options I'm setting are actually doing anything.
Thanks
I guess the first step in debugging is figuring out whether te faillure occurs on sending or receiving.
Can you send this message to a different kind of webservice?
Can you receive this message from a different tool into NiFi?
You don't mention how large the messages are, but it seems that in sending you try to set the limit to 50MB.
I don't think this is a problem for NiFi in general, but if you are specifically using multipart/form-data the default limit is set to 1MB.
This could be adjusted via the setting: Multipart Request Max Size
I'm writing a simple api for training using express. Here's my testing code:
var express = require('express');
var app = express();
app.post("/api/:var_name", function(req, res) {
res.send(req.params.var_name);
});
is simply testing to see if POST is working. When I call http://localhost:3000/api/1 I get Cannot GET /api/1, so the server is obviously interpreting the POST request as GET, what do I need to do to call POST instead?
Anything you call in the address bar of your browser will be sent via get. This is due to the fact that post-messages (and almost all other methods) do have a body-part. But there is no way for your browser to send additional information inside the body of the http packet.
If you want to test your routes for any method other than GET I would suggest you download a tool like postman.
https://www.getpostman.com/
BEWARE: This is my preference. You can of curse also use text based browsers like curl to test it.
The server interprets the request according to the verb you set in the HTTP request. If no method/verb is specified it is interpreted as GET(not sure about this part).
When you call that URL, you need to use the method as well. For example if you use the fetch API, you can call it like:
fetch(url, {method:"POST"})
If you're entering it in your browser and expect it to be interpreted as a post request, it's not. All browser url requests are GET. Use a tool like Postman to call different HTTP verbs. It's really useful when creating such APIs.
You can check out this answer on details of how to add body and headers to a post request: Fetch: POST json data
I want to upload files using FormData Object(html5) in dojo and without using XmpHttpRequest.
I am using dojo.xhrPost to upload files.
Please post your ideas/thoughts and experience.
Thanks
Mathirajan S
Based on your comment I am assuming you do want to use XHR (which would make sense given that FormData is part of the XHR2 spec).
dojo/request/xhr (introduced in Dojo 1.8) supports passing a FormData object via the data property of the options object, so that may get you what you want.
request.post(url, {
data: formdataObjectHere
// and potentially other options...
}).then(...);
The legacy dojo/_base/xhr module does not explicitly support XHR2, but it does lean on dojo/request/xhr now, so it might end up working anyway, but no guarantees there.
More information on dojo/request/xhr can be found in the Reference Guide.
I'm using signed POST to upload file directly to amazon S3. I had some trouble with the signature of the policy using PHP but finally fixed it and here is the sample of code.
This xhr request is send in javascript and I'm waiting for an answer from amazon. At first I was using success_action_status setting it to 201 to get the XML response.
What I'd like to do is using the success_action_redirect to call a script on my server to create a record in the database.
The reason why is that I could create the record in the database and if anything wrong happen at this stage I can return an error message directly at this point. Also it saves me another ajax request to my server.
So I've tried to set this up specifying the success_action_redirect to http:\\localhost\callback.php where I have a script that is waiting for some parameters.
But it looks like this script is never called and the response of the xhr.send() is empty.
I think it's a cross-browser issue and I'm wondering if it would be possible to use jsonp somehow to pass-by this?
Any ideas?
UPDATE
Apparently xhr is following redirect natively so it should work but when I specified the success_action_redirect it returns error Server responded with 0 code.
At first I thought it was because the redirect URL was on my local server so I've changed it to an accessible server but no chance.
Anyone knows why it's returning this error message?
I also run into this problem. It seems like nobody has a solution to this like this
maybe the best workaround i have found is something like this.
It seems thet the only workaround includes a second xhr-request to execute the callback manually. therefore the
success_action_status
should be used. Witht his you will get a 201 response if the upload was successful and you can start a second request for the actual callback. For me it looks like the only possible solution at the moment.
Any other solutions?