search

Tectu / malloy

A cross-platform C++20 library providing embeddable server & client components for HTTP and WebSocket.
BSD 3-Clause "New" or "Revised" License
66 stars 8 forks source link

HTTP client: Automatically follow redirects #35

Open Tectu opened 3 years ago

Tectu commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.