I think we can do 2 things here (and by that I also mean I can implement it and make a PR):

1. Fix check's not working for codes 301/302 without breaking compatibility with existing installations

For that let's assume that a HTTP check succeeds when its expected status code matches the status code of the final response OR the first response of a chain of requests (it there was a chain).

So for example if my check expects 302 and my response chain is: 302 ➡️ 301 ➡️ ... ➡️ 200 then my check succeeds because first response code matches. It will also succeed if my check expects 200.

We can easily use requests history feature to implement this.

Advantages of this change is that this will keep checks "just working" for most users and will not break compatibility with existing installations.

A possible disadvantage of this change is that is not a very obvious behavior and this may break Cabot's simplicity promise.. Also we will not fix @maxstepanov problem this way.

For that we need to

2. Make HTTP checks globally or locally configurable to follow/not follow the redirections.

Of cource this should be disabled by default, as @dbuxton has written above.

I that was my decision then I would be leaning towards global configurability here to KISS & make up for the additional complexity of the change described above. :)

Also, and more seriously, apparently this feature is not very much needed if it was not touched / requested by anyone for the last ~9 months so the simpler global approach will probably be enough.

@dbuxton What do you think? Should I implement it both?

Uh oh!

Following redirects on HTTP Checks #20

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions