search

mulesoft / api-console

An interactive REST console based on RAML/OAS files
Other
910 stars 236 forks source link

Try it should not follow redirects #285

Closed ibnesayeed closed 4 years ago

ibnesayeed commented 8 years ago

Some API endpoint may be there to only provide redirect responses (such as URL shortner services). In such cases it is more important to know what headers and payloads such endpoints return rather than allowing Try it to follow the redirect and report based on the terminal response.

ibnesayeed commented 8 years ago

It looks like it is not possible because browsers transparently follow redirects.

nmarinel01 commented 7 years ago

Hi @ibnesayeed ! Thanks for your contact. Im closing this question now, but please, feel free to reopen it if applies. Regards !

ibnesayeed commented 6 years ago

I think this ticket should be reopened and the question label should be removed as there is now a way to implement it. If we use the Fetch API for Try It, we can set the redirect mode of the request to manual to avoid transparent redirects.

/cc @agustinlg and @nmarinel01

jarrodek commented 6 years ago

I am not using neither Fetch or HXR api. I am using own http client for JavaScript. It is possible to do it and it's on the roadmap. However to implement it, it would require several additional changes including UI to setup request options, save request module, open request module, export request data module and finally import data module. Possibly it's more than that. So I will start to implement it when I am sure I have time to finish it :)

jarrodek commented 6 years ago

Sorry, ignore my previous comment. I thought I am commenting on different repository. There's no plans so far to do it for the API console. I see no reason to do it. API console follows behavior defined in RAML file and RAML spec doesn't define behavior in case of redirection.

ibnesayeed commented 6 years ago

I am not using neither Fetch or HXR api. I am using own http client for JavaScript.

These are primitive methods exposed by the browser, so no matter what custom implementation you might be using, you would end up using one or the other of these (excluding ActiveX, Flash, and JSONP style trickery here). And I can see fetch being used in ram-request-pannel (I am not sure if that is the relevant place though).

ibnesayeed commented 6 years ago

I see no reason to do it. API console follows behavior defined in RAML file and RAML spec doesn't define behavior in case of redirection.

I would differ here because it is not the responsibility of RAML to tell how to handle redirects. From the perspective of RAML, a 1xx, a 3xx, a 4xx, or a 5xx response is just yet another response that is equally as accurate and valid as a 2xx response. The documented response with precise response code is expected when interacted with the service from any client. For example, using curl without explicit -L (follow redirect) flag, it should show what is documented. Unfortunately, it was not possible to replicate that behavior in the browser because in the XHR specs it was decided that browsers should transparently follow the redirect without giving the user or application any control on it. This decision was limiting in Service Workers, so they allowed a manual mode in the Fetch API. I really see no reason why it should not be utilized here in the Try It. Actually, I think it will be good to have a small chekbox in the Try It interface to explicitly enable following redirects, but do not follow it by default.

jarrodek commented 6 years ago

Similar to my comment here: https://github.com/mulesoft/api-console/issues/553#issuecomment-364531392 I will investigate this further in about a week.

jarrodek commented 4 years ago

This feature request won't be supported in the console. It will follow browser's default behavior.