Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always follow redirects in network jobs #4905

Merged
merged 1 commit into from
Aug 9, 2016
Merged

Always follow redirects in network jobs #4905

merged 1 commit into from
Aug 9, 2016

Conversation

danimo
Copy link
Contributor

@danimo danimo commented May 26, 2016

This is a move away from the original policy where jobs would only follow
redirects in special cases.

Two restrictions are in place:

  1. We do not allow protocol downgrades (https -> http)
  2. We stop redirects after we find them looping (e.g. old = new url, or indirectly when looping 10
    times).

This is closer to RFC conforming behavior, although currently we will treat
301 replies like they were 302. This is for a separate commit.

@mention-bot
Copy link

By analyzing the blame information on this pull request, we identified @ogoffart, @ckamm and @dragotin to be potential reviewers

@ogoffart
Copy link
Contributor

👍

@ogoffart
Copy link
Contributor

ogoffart commented May 26, 2016

Actually, since _followRedirects is always true, we could get rid of it.

@danimo
Copy link
Contributor Author

danimo commented May 26, 2016

@ogoffart I intentionally left it there for jobs to customize, but we could just as well kill it.

@danimo
Copy link
Contributor Author

danimo commented May 26, 2016

Olivier also mentioned that this change makes HTTP only connections prey to redirects from mobile hotspots, which could mess with data integrity. We need to find a good solution here, even if it means disabling redirects for HTTP only.

@guruz guruz added this to the 2.3.0 milestone May 30, 2016
@guruz
Copy link
Contributor

guruz commented May 30, 2016

👎 Please mention the issue ID in the commit and check if this confirms..
#2791 (comment)

@danimo danimo modified the milestones: 2.2.2-maybe, 2.3.0 Jun 2, 2016
@guruz
Copy link
Contributor

guruz commented Jun 28, 2016

Behaviour change, move to 2.3?

@guruz guruz modified the milestones: 2.3.0, 2.2.3 Jul 12, 2016
This is a move away from the original policy where jobs
would only follow redirects in special cases.

Two restrictions are in place:

1. We do not allow protocol downgrades (https -> http)
2. We stop redirects after we find them looping (e.g. old = new url, or
indirectly when looping 10 times).

This is closer to RFC conforming behavior, although currently
we will treat 301 replies like they were 302. This is for a separate
commit.

Error handling (and display) also needs improvement.

Addresses #2791
@ogoffart
Copy link
Contributor

ogoffart commented Aug 9, 2016

👍

@guruz
Copy link
Contributor

guruz commented Aug 9, 2016

We discussed irl that this is not as dangerous as we thought and that we should go for it.

@danimo
Copy link
Contributor Author

danimo commented Aug 9, 2016

@guruz: build has passed. +1?

@guruz
Copy link
Contributor

guruz commented Aug 9, 2016

I don't want to take responsibility for this
@ogoffart already approved.
I guess it's OK.

@danimo danimo merged commit bb5c2cb into master Aug 9, 2016
@danimo danimo deleted the redirect branch August 9, 2016 14:02
@SamuAlfageme SamuAlfageme mentioned this pull request Feb 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants