redirect status when 200 expected

[acousticrobot]

I was expecting a 200 status with HTTP.get("https://kb.uwplatt.edu"), as is the case with Net::HTTP, curl etc. but received a 302. I saw something in the documentation about using follow.get for redirect but this resulted in a EndlessRedirectError. We were using your gem to validate URLs when this came up, and this is the first one that I'm aware of where the result was unexpected. Am I doing something wrong here, or is there something specific about this url that I'm not seeing? Thanks.

[ixti]

Well, there's a little bit of "something" specific with that URL:

• GET https://kb.uwplatt.edu redirects to https://kb.uwplatt.edu/dm.php?...
• GET https://kb.uwplatt.edu/dm.php?... responds with Set-Cookie and redirects back to https://kb.uwplatt.edu

We can amake this bit configurable I guess with something like:

HTTP.follow(:max_repeats => 2) # default: 1

[natesholland]

I'm starting to look into this one. @ixti and @acousticrobot what do you think the desired behavior would be here? I see a few options:

• After a certain number of repeats simply return the latest 302
• After a certain number of repeats raise an EndlessRedirectError. Note that this wouldn't solve the problem described in this issue because it really does look like a loop.
• After a certain number of hops return the latest 302. This is like max_hops but instead of raising we return the last 302 we got.
• After a certain number of hops then raise - This is basically what max_hops does so I don't think there's any value here.

I think the first option is the best one that solves the problem described in this issue, but the second option is my favorite over all. It's basically adding a threshold for how long we're allowed to loop before blowing up.

[natesholland]

I made a draft for what this could look like in #550. I need some feedback on the desired behavior and then I can work on building it into something that is actually ready to merge and looks pretty.

[ixti]

@natesholland After thinking a bit about this issue again - I think it's unsolvable with current approach. It's something that needs to be part of http session, as loop breaks only if client re-sends request with cookie he received on previous hop.

Right now the best option to solve this particular issue I think is to refactor redirector to accept #request responding object to initializer and using it, so that one can provide a tiny wrapper for HTTP::Client that would handle cookie getting/setting.