HTTP client: Automatically follow redirects

[Tectu]

The HTTP client should provide a setting that allows the user to control whether redirects are followed automatically.
Currently, redirects are not followed automatically.

I'm considering adding this for the initial v0.1 release.

[Tectu]

@0x00002a do you see any scenario that would justify implementing this in a way that a user can inspect whether one or more redirects were followed or should this just happen completely transparent to the user?

One such use case I'd see is when implementing something like a RestAPI testing tool (eg. something like Postman or Insomnia). However, with an application that requires such a level of control a developer is likely to implement redirect following as a custom feature anyway, eg. to compile a timeline.

Thoughts?

[0x00002a]

iirc curl does not provide any way of checking whether redirects were followed, it just provides the FOLLOW_LOCATION option. My main use case for malloy client-side is replacing C style curl code. Like you said, theres nothing stopping the user from inspecting the response's result, finding its a redirect and doing the logic themselves if they want that level of control

[Tectu]

@0x00002a how busy are you currently? I'd really like to move to the first release ASAP to make maintaining applications consuming this library easier and hopefully also attracting more users & contributors.

Do you feel like giving this a go?

[0x00002a]

This is proving non-trivial. In the case of http redirects that go to a different host, we are going to have to parse the url provided to actually get that host so we can pass it to the resolver. I'm not sure if I should try writing code to do this, since anything I do write is going to be quite naive and certainly not cover all cases. I can implement this partially (without support for redirects to a different host) though.

Really I think malloy might need to depend on a url library for this sort of thing.

Thoughts?

[Tectu]

Yeah, I have been looking at this for a while now. It didn't even have an alpha release when I started writing this library. That's why I added my own quick'n'dirty uri class (remember that one, eh?).

Do you know of any decent alternatives?

[0x00002a]

None that I've used. I too like the look of Boost.URL, but as far as I can tell it is in no way ready for use yet. this (github repo) looks pretty nice and is something I was investigating for my own code, but I haven't actually used it.

[Tectu]

I think we should aim for not including this in the initial v0.1 release given the complexity / nature of intrusive changes if we implement it properly.