How does superdeno intercept redirects?

[viztastic]

Is there a way to test for redirects?

When I do something along the lines of:

    await superdeno(testApiUrl)
    .post('/api/to/endpoint/that/triggers/a/redirect')
    .expect((response, error) => {
       assertEquals(response.status, 302);
        assertEquals(response.headers.includes('location: http://google.com/'), true);
    });

This errors out and insists that the final state is 200, not 302.

I've noticed that the response.headers capture those of the final destination page rather than the actual API redirect state. Is there a way to go one step before the final destination URL?

I have also tried

    await superdeno(testApiUrl)
    .post('/api/to/endpoint/that/triggers/a/redirect')
    .expect(302)
    .expect((response, error) => {
        assertEquals(response.headers.includes('location: http://google.com/'), true);
    });

but to no effect.

Thanks heaps (again great library).

[asos-craigmorten]

Ah, interesting - great point!

So it looks like superagent supports redirects (by default it will follow up to 5) (REF: https://visionmedia.github.io/superagent/#following-redirects) and so really we should be exposing the .redirects(n) method through SuperDeno as well.

Will need to investigate whether we're re-exposing this functionality properly in SuperDeno - might require a fix in the xhrSham we are using, but should be simple enough given fetch supports a redirect property in it's Request object (REF: https://developer.mozilla.org/en-US/docs/Web/API/Request).

(P.S. this is just a port of supertest - most credit should be directed there!)

Let me know if you have any luck with using .redirects(n), if it works then fab! Otherwise will try spare some time to dig into and fix this soon (unless there are any other takers!)

[asos-craigmorten]

Started having more of a dig - it looks like the browser implementation that we are using for superagent does not support the .redirects(n) API.

I'll make a stab at implementing it.

[asos-craigmorten]

Sorry to be the bearer of bad news, but unfortunately it looks like this would be no small task without change to the whatwg spec for fetch, and then that change implemented in Deno core.

The easiest / main way to make a HTTP request in Deno is to use the fetch API. This however has no support for stepping through redirects. It has a somewhat misleading redirect: manual option, but this in effect stops the redirect and then returns blank information regarding the response meaning it is impossible to determine what the status and url of the redirect were (or anything else for that matter). There is some discussion around whether the Location or other useful information should be exposed in these cases here: whatwg/fetch#576, but it isn't looking likely to be implemented any time soon, if at all.

Deno also has no intention to implement the XMLHttpRequest API (REF: denoland/deno#2191), so that is out of the question.

What remains is to use a reasonably hand-crafted (non-standard) method of making HTTP requests such as how https://github.com/keroxp/deno-request or https://github.com/keroxp/deno-fetch has done it with Deno.dial.

Maybe I'll spike a branch, but feel a little hesitant to move away from using fetch under the hood for something bespoke!

[viztastic]

Yeah that's fair enough. Might be worth waiting until Deno implement XmlHttpReq and see where that goes. Appreciate the detailed insights on this.

[avihavai]

Hi! The Deno 1.6.0 release changed the behavior of fetch (REF), making it possible to test redirects.

As an example, when a server at port 7777 redirects requests to path /path-redirected-to, the following output will be given when using manual redirects:

const res = await fetch('http://localhost:7777', {
  redirect: 'manual'
});
console.log(res);

{
  _bodySource: null,
  _stream: null,
  url: "http://localhost:7777",
  statusText: "Found",
  status: 302,
  headers: Headers { content-length: 35, location: /path-redirected-to, content-type: text/plain; charset=utf-8 },
  redirected: false,
  type: "default"
}

The new behavior also provides an opportunity to step through redirects. The cors option used in superdeno continues to follow through redirects.

Should I open a new issue asking for the possibility to test redirects in superdeno/superoak (e.g. by changing the default redirect behavior or by giving the users an option to input the redirect mode), or should we use this issue for following up? And, awesome work on superdeno & superoak!

[cmorten]

Oh wow! Completely missed this 😄 Clearly oogling too much at the LSP and deno compile to read the changelog properly! Let's reopen this issue and use it to track 🚀

Need to have a play around, but from what you describe I reckon we should be able to support the superagent redirects() API 🎉

Thanks for raising this @avihavai 💯

[cmorten]

@avihavai, @viztastic support for a .redirects(n) API (as per superagent and supertest) has been released in 3.0.0.

I hope this helps with any missing test coverage you might have! Please raise new issues if you have any problems with it 🙃

[avihavai]

Awesome, this works brilliantly. Thanks a lot for the effort!