New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cancel HTTP request #3243

Closed
MattiSG opened this Issue Dec 6, 2014 · 8 comments

Comments

Projects
None yet
4 participants
@MattiSG

MattiSG commented Dec 6, 2014

As a caller of an external API,
I would like to cancel an outgoing HTTP.call request,
To enforce proper ordering of results and minimising load


Example usage:

    // in some template's events
    'keyup #someInput': function(event) {
        Session.get('request').cancel();  // <- I would like to do this

        var newRequest = HTTP.call('GET', 'http://someapi.com/api/v1/convert', {
            params: {
                filter: event.target.value
            }
        }, function(error, result) {
            Session.set('results', result.data.value);
        });

        Session.set('request', newRequest);
    }
@smeijer

This comment has been minimized.

smeijer commented Dec 9, 2014

We indeed do need access to the xhr.abort() method.

I need to be able to abort large sized file uploads. Or indeed, abort request that where executed prior to the currently running, like for example an auto completion form that uses a external source. The completion form should cancel running requests, when the user starts typing again.

@glasser

This comment has been minimized.

Member

glasser commented Jan 12, 2015

For what it's worth, you can just use the underlying XHR and Node request libraries directly when the basic easy-to-use HTTP.call doesn't provide all the detailed features that you need.

@MattiSG

This comment has been minimized.

MattiSG commented Jan 12, 2015

Interesting. How are they exposed?

@glasser

This comment has been minimized.

Member

glasser commented Jan 12, 2015

They aren't exposed by Meteor. They are just part of your browser! (Especially on the client, HTTP.call is a pretty thin layer over XHR.)

@glasser

This comment has been minimized.

Member

glasser commented Jan 12, 2015

Thanks for the feature request! You might be interested in reading our feature request guidelines.

@MattiSG

This comment has been minimized.

MattiSG commented Jan 13, 2015

They are just part of your browser!

Ok… but I thought one of the advantages of HTTP.call is isomorphism. If I have to use XHR or its jQuery wrapper, I feel like Meteor failed its job (but perhaps I'm wrong!). Documenting the limitations and workarounds directly next to HTTP.call would ease the pain.

Also, in the browser, I see how the API is exposed. But how is it exposed in the server? Should I Npm.require('request')? How am I supposed to know which module is bundled with Meteor?

@MattiSG

This comment has been minimized.

MattiSG commented Jan 13, 2015

You might be interested in reading our feature request guidelines.

I just read it, and don't feel like anything has to change in this request now that you tagged it. Please correct me if I'm wrong.

@robertpitt

This comment has been minimized.

robertpitt commented May 20, 2015

I too concur with the FR/Issue brought up.

I have developed an extra layer on top of meteor:http in order to control REST Flow to one of our API services but we have to resort to other means in order to things like uploads.

here: https://github.com/Centiq/centiq-crest

You claim that the http library isomorphic but that's already broken with the following:

/packages/http/httpcall_client.js#L52

  if (options.followRedirects === false)
    throw new Error("Option followRedirects:false not supported on client.");

  if (_.has(options, 'npmRequestOptions')) {
    throw new Error("Option npmRequestOptions not supported on client.");
  }

In regards to a solution, as you have already strayed away from being 100% isomorphic, adding the ability to intercept the XHR object before the send call would allow us to control a lot more of the request on a per application basis.

jQuery has an option called beforeSend within it's $.ajax calls to allow us to do the things that is not baked in.

If Pull request's are encouraged for this I don't mind putting in the work if we can agree on a api for it.

API suggestion:

http.get(path, _.extend(options, {
    /**
     * @var request XHR On the client, request on the server
     */
    beforeSend: function(request){

    }
}))

Solves a lot of issues and allows libraries to do more interesting things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment