-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
support redirect requests natively #808
Conversation
I just noticed the RedirectHandler CopyResult uses a .Result. That's because I pulled the code from a .net 4.0 project. It should probably be fixed to use async/await. I'd do it but I'm not sure how to add a commit to a PR. |
Thanks for digging into this, @shiftkey. ⚡
My C# leaves much to be desired, but @kdaigle and I sketched out this plaintext spec that might help answer your question:
Does that help? |
|
@darrelmiller if you're working on your fork and it's in a branch I know about, I can pull in your changes into this PR... |
@shiftkey I don't really know how. But I succeeded in pushing my changes to my fork. darrelmiller@cf9c845 |
Couple of comments: The 301 and 302 behaviour is now different to what HttpWebRequest does by default. But the new behaviour is what was originally intended for 301/302. (Possibly the most useful diagram I have ever seen on this subject is here https://tools.ietf.org/html/rfc7238#section-1) Keeping the auth header around based on host is consistent with what the .Net CredentialCache does. However, based on my interpretation of the HTTP specs, it should really be based on the realm. Which would require a 401 dance to find out the new realm. I would file this under "nice idea in theory but no-one does it". The pedant in me felt the need to mention it. |
@darrelmiller: Thanks for linking to that diagram. Wonderfully succinct and useful. ⚡ |
@darrelmiller your latest changes are applied onto this PR - thanks for that 💖. i'll look at those failing tests, and putting together some additional tests for the GitHub API. |
@@ -109,6 +103,8 @@ protected virtual HttpRequestMessage BuildRequestMessage(IRequest request) | |||
{ | |||
var fullUri = new Uri(request.BaseAddress, request.Endpoint); | |||
requestMessage = new HttpRequestMessage(request.Method, fullUri); | |||
|
|||
requestMessage.Properties["AllowAutoRedirect"] = request.AllowAutoRedirect; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@darrelmiller I'm almost inclined to obsolete request.AllowAutoRedirect
and simplify things - as we need to control this behaviour in our very specific way. Any objections?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It felt like a nice feature to have, but I'm struggling to think of a scenario where I would actually need it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was one of the first things I'd removed when refactoring earlier attempts. Good enough for me 🔥🔥🔥🔥🔥
Just added a passing test against the new redirects - I'll add some more later this week, but this is feeling rather close... |
👍 |
Added in a test for issue creation and finding a repository. Ready for review. |
Just added one more little task before I'm happy with this. |
Conflicts: Octokit/Octokit-Mono.csproj Octokit/Octokit-MonoAndroid.csproj Octokit/Octokit-Monotouch.csproj Octokit/Octokit-Portable.csproj Octokit/Octokit-netcore45.csproj
Extracted #817 rather than drag this out any longer. Ready for review 🐶 |
@haacked would love some 👀 on this before I merge it and continue down the path of extracting more HTTP-friendly abstractions... |
Just one observation that would probably have been much more useful before we started all this. If you are actually using the CredentialCache with credentials associated to the correct origin server, then when you redirect to a URL with the same host then the credentials are carried over. Using a credential cache avoids setting creds in a default header and takes care of applying the correct credentials on every request. Maybe it shouldn't be the responsibility of redirection code to be carrying over the authorization header. |
Yep, I'd like to address this at some point - we should mimic this behaviour in our abstraction and move it into |
Funny you should mention that, but I just finished writing an AuthenticationService/HttpCredentialCache that plugs into the message handler pipeline. It's not on Github yet though. |
@haacked bump for code review plz |
Not worth commenting on in a code review, so I fixed it myself.
var redirectCount = 0; | ||
if (request.Properties.Keys.Contains(RedirectCountKey)) | ||
{ | ||
redirectCount = (int)request.Properties[RedirectCountKey]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't this fail if there's no value here? Or do we always seed this with a value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would only fail if someone pre-filled the property with a value that cannot be cast to an int. A value is assigned to the property when it is initially created, right after this If ends.
Looks good to me. Just one question. |
support redirect requests natively
@darrelmiller @shiftkey: 👏 🌟 |
Fixes #798
Fixes #748
Fixes #812
Building on the awesome start that @darrelmiller started over in darrelmiller@e5d7d6e
https://github.com/robconery/massive
->https://github.com/fbouma/massive
307
RepositoryContentsClient.GetArchiveLink
depends on not following the redirect, prolly need to address this@jasonrudolph anything I've missed here?