Pass a Uri to package:http APIs

[natebosch]

Prepare for dart-lang/http#375

[ditman]

Thanks for the fix @natebosch, before merging we'll have to bump the version in the pubspec + CHANGELOG so this becomes publishable!

[natebosch]

I bumped to a -dev version so it is clear this has changed since it was last published. https://github.com/dart-lang/sdk/wiki/External-Package-Maintenance#making-a-change

There is no need to publish just for this - it won't have any real impact for places where it is fetched from pub. Where this will make a difference is google3.

[ditman]

I need to do a quick real world test with this, I remember Safari having trouble when parsing Blob URLs before doing the ajax fetch. I'll merge this once that's done.

Also, there's a similar package: cross_file that might need a similar fix to this (but it's probably not imported into g3), I'll take care of that one!

[natebosch]

I need to do a quick real world test with this, I remember Safari having trouble when parsing Blob URLs before doing the ajax fetch. I'll merge this once that's done.

There should be no impact. That Uri.parse call happens today already, it's just happening deep in the http functions instead of at the call site.

https://github.com/dart-lang/http/blob/d473635f0dbb72936664696162127c2209986356/lib/src/base_client.dart#L110

Also, there's a similar package: cross_file that might need a similar fix to this (but it's probably not imported into g3), I'll take care of that one!

Thanks!

Note that this won't have an impact on any package until it changes it's dependency constraints in pubspec.yaml. This will come with a major version bump in http. The main reason I need to do google3 packages in advance is because pubspec constraints don't have any impact there.

[natebosch]

It looks like tests are failing due to the -dev suffix on the version I mentioned in #3309 (comment). This is a pattern that we use to indicate when the code in the repo does not match the code as published under that version, and until we go to do a publish we don't know whether the code will match.

Since this repo doesn't take that approach which is prefered - do you eagerly bump the version when the code changes even without user facing changes, or do you wait to bump the version until there is a user facing change to document in the changelog?

[ditman]

do you eagerly bump the version when the code changes even without user facing changes

@natebosch yes, let's bump the minor version and document in the CHANGELOG that this passes Uri objects instead of Strings to package:http methods. I can do this, now that you've touched the files themselves from the web UI, I think!

Thanks for the clarification about the major version and the links to the http source!

[ditman]

LGTM, thanks for the fix @natebosch!

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[ditman]

@googlebot I consent.