Is there a way to config the 4xx & 5xx statusCode as normal response but not error

[magicdawn]

As the title presents.

I'm tired of writing code like this

const getDataAsync = co.wrap(function*(){
  let res;
  try {
    res = yield request.get('some_url')
  } catch(err) {
    if(!err.original && err.response) {
      res = err.response
    } else {
      throw err;
    }
  }
});

I have to test !err.original && err.response exists, and treat it as success response, I'm tired of writing this.
So I'm asking is there a way to config that and if not can this issue be a feature request?

[magicdawn]

Actually I'm talking about this: https://github.com/visionmedia/superagent/blob/v2.2.0/lib/node/index.js#L594-L601

[focusaurus]

I think this is one of those API decisions that could go either way. Either you write application code like that to treat responses with error status codes as successful responses or you change the superagent API to treat them as success, but then you have to write application code to look at the status code in the application and respond accordingly. For example, detecting a 404 with HTML in the body when you were expecting a 200 with JSON.

I personally wish the original superagent API was "any HTTP response is success" semantics, but it's not. This is something that would be such a breaking change I'd hesitate to change it without something as drastic as forking and renaming the project. I believe that has been discussed on github issues in the past so you might get some insight searching through closed issues for discussion.

I know of at least request-promise which has this behavior configurable:

By default, http response codes other than 2xx will cause the promise to be rejected. This can be overwritten by setting options.simple = false.

I would hesitate to make the core API configurable in this way, but I do understand your frustration.

[magicdawn]

So since request-promise add configuration to this, how about superagent 🎉

[focusaurus]

Well, if we do it, I'd rather do it with a different API like adding a
req.getResponse() method.

On Fri, Sep 16, 2016 at 8:37 AM Tao notifications@github.com wrote:

So since request-promise add configuration to this, how about superagent
🎉

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#1069 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdcSWMICCSs4_mdiiGXpj2Ud6o_nYSkks5qqqmlgaJpZM4J-1Q4
.

[kornelski]

I think we could make the logic configurable by allowing user to supply a callback to judge whether the response is OK.

https://github.com/visionmedia/superagent/blob/v2.2.0/lib/node/index.js#L590

request.get().ok(res => res.status < 500).then(…)

[magicdawn]

ping

[magicdawn]

idea: global staticProperty

add a static property superagent.detectStatusCode

• defaults to true, so we treat 4xx & 5xx response as error
• when set to false, wo do not care the statusCode

[magicdawn]

idea: per req config

add a property or method to the superagent.Request class
e.g add Request.prototype.config

request
  .get('https://www.google.com.hk')
  .config({ detectStatusCode: false }) //  <- turn off detectStatusCode here
  .end((err, res) => {
    // ... blabla
  });

I'm 👍 on this too

[magicdawn]

.ok is also ok

but add support short version like .ok(true) would be more nice

[magicdawn]

ping

[keithamus]

request.get().ok(res => res.status < 500).then(…)

Very much works for me. I think if you want all to pass, request.get().ok(_ => true) is very succinct.

[Joshua-Swain]

I'm trying to use this function for to test an invalid post request. The function goes like this: chai.request(app).post(...).set(...).send(...).end((err, res) => {...});
I tried putting .ok(...) at every point in that chain, but I always received the error TypeError: chai.request(...).post(...).set(...).send(...).end(...).ok is not a function

I am expecting this to cause validation errors. Any advice on how to use this ok() feature?

[kornelski]

This feature is in superagent. Are you using supertest perhaps?

[Joshua-Swain]

I'm pretty sure I'm using superagent, because I'm using chai out of the box.

[kornelski]

Then request.post(url).ok(cb) should work. chai.request(app) doesn't look like a call to superagent, so maybe chai has a wrapper that doesn't expose it yet?

[focusaurus]

I believe the chai-http plugin is in use here. That has superagent 3.7 which should have .ok I believe so not sure what's wrong.

[keithamus]

(chai-http maintainer here) We've yet to add support for this feature in a released version of chai-http. We'll be making a release soon. Thanks for everyone's input here.

[svicalifornia]

@keithamus Any update? What should we be doing until ok is added to chai-http?

[keithamus]

@svicalifornia we should take this off of the superagent tracker. Please track chaijs/chai-http#202 for updates.