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
Related
I've been trying to make use of service.getNavigation() method, but apparently the Request URI is too long which causes this error:
Request-URI Too Long
The requested URL's length exceeds the capacity limit for this server.
Is there a spartacus config that can resolve this issue?
Or is this supposed to be handled in the cloud (ccv2) config?
Not sure which service are you talking about specifically and what data are you passing there. For starters, please read this: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/414
Additionally it would benefit everyone if you could say something about the service you're using and the data you are trying to pass/get.
The navigation component is firing a request for all componentIds. If you have a navigation with a lot of (root?) elements, the maximum length of HTTP GET request might be too long for the given client or server.
The initial implementation of loading components was actually done by a POST request, but the impression was that we would not need to support requests with so many components. I guess we were wrong.
Luckily, the legacy POST based request is still in the code base, it's OccCmsComponentAdapter.findComponentsByIdsLegacy.
The easiest way for you to use this code, is to provide a CustomOccCmsComponentAdapter, that extends from OccCmsComponentAdapter. Then you can override the findComponentsByIds method and simply call the super.findComponentsByIdsLegacy and pass in a copy of the arguments.
A more cleaner way would be to override the CmsComponentConnector and directly delegate the load to the adapter.findComponentsByIdsLegacy. I would not start here, as it's more complicated. Do a POC with the first suggested approach.
I have a working hapi service, complete with hapi-swaggered and hapi-swaggered-ui. This is useful for many cases, but I want to add a build step to my CI which will be able to get the JSON generated by hapi-swaggered (which, if changed, would get compiled that into an .Net assembly that gets stored in a local proget).
I know that if I really wanted to, on my build server, I could start an instance of my server, curl to localhost:3000/swagger, kill the server, and proceed, but that seems a little risky (i.e., what if I have two builds running at the same time?).
Has anyone developed a way to directly call the hapi-swaggered API to get the raw JSON?
Well, that didn't take too much longer, but I think I found one solution. In this case, internals is my server. It does not auto-start if its loaded (required'ed) from another file, and the compose method is exposed to use hapi's Glue.compose to assemble the service. It seems that I can then use the inject method to simulate a call.
'use strict';
var internals = require('./');
internals.compose(function(err, server) {
server.inject({ method: 'GET', url: '/swagger' }, function (response) {
console.log(JSON.stringify(response.result));
process.exit();
});
});
If there's anything that I'm missing about this technique, I'd like to hear about it.
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?
Rails 3.0.10 and activemerchant gem 1.29.3
My app works fine in sandbox, but transactions in production mode are failing with "Security header is not valid", "ErrorCode"=>"10002"
We initiated a support request with paypal, after reviewing all the configuration parameters a million times and they feel we're hitting an incorrect endpoint. They've asked for a full trace for the transaction, including headers, etc, so I'm trying to figure out how to do that. I found this article
which suggested adding this to the config block
ActiveMerchant::Billing::PaypalGateway.wiredump_device = File.new(File.join([Rails.root, "log", "paypal.log"]), "a")
But that just results in an empty log; nothing gets dumped to it.
So, how can I obtain this info from the GATEWAY object, if possible? Here's the production config, the format of which is identical to what's used in staging env.
::GATEWAY = ActiveMerchant::Billing::PaypalGateway(
:login => 'me_api1.blah...',
:password => 'string...',
:signature => 'longer string...'
)
Thanks.
Needed to add the additional line as follows:
ActiveMerchant::Billing::PaypalGateway.wiredump_device.sync = true
Within the same config block in the environment
Somewhere in the class library you're using there should be a function to output this for you (if it's a well built library, that is.)
Even without that, though, you should be able to look in that PaypalGateway function to see where/how it's setting the endpoint. It's either hard-coding the value or it'll be setting different endpoints based on some sandbox option you have configured somewhere else in the class.
It's hard to tell you more than that without getting a look a the actual class library you're using, but I can concur that it must be either incorrect credentials or an incorrect endpoint. I've never once seen that security header error when it wasn't simply invalid credentials, which means either your values are incorrect or you're hitting the wrong endpoint.
If you want to post that whole function (or maybe even the whole library as the endpoint could be getting set from some other function) I can take a look and find the problem for you.
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.