Bug 1767292 Comment 13 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to :Gijs (he/him) from comment #12)
> (In reply to Sean Kim from comment #11)
> > Noticed an interesting behaviour. When I tried to run `./mach run http://httpbin.org/basic-auth/user/pass`, I noticed that `args.channel.URI.prePath` is set to `https://httpbin.org` instead of http (url bar still says `http://httpbin.org/basic-auth/user/pass`). Is this an intended behaviour?
> 
> Is https-first/only definitely not turned on? This seems like a networking question, I don't really know what would cause the channel URI to be different from the URL bar here... if you "complete" the navigation by putting in a user/pass, do you end up on https or http, and does the URL bar update then?

The issue I mentioned was due to `NewProxiedChannel`, which I think was expected. If we navigate to `http://httpbin.org/basic-auth/user/pass` through the URL bar, it does show up the broken favicon. It should end up on https or http, depending on how `URI`'s scheme (not `originalURI`), at least based on what I just tested.
(In reply to :Gijs (he/him) from comment #12)
> (In reply to Sean Kim from comment #11)
> > Noticed an interesting behaviour. When I tried to run `./mach run http://httpbin.org/basic-auth/user/pass`, I noticed that `args.channel.URI.prePath` is set to `https://httpbin.org` instead of http (url bar still says `http://httpbin.org/basic-auth/user/pass`). Is this an intended behaviour?
> 
> Is https-first/only definitely not turned on? This seems like a networking question, I don't really know what would cause the channel URI to be different from the URL bar here... if you "complete" the navigation by putting in a user/pass, do you end up on https or http, and does the URL bar update then?

The issue I mentioned was due to system prefs, which I think was expected. If we navigate to `http://httpbin.org/basic-auth/user/pass` through the URL bar, it does show up the broken favicon. It should end up on https or http, depending on how `URI`'s scheme (not `originalURI`), at least based on what I just tested.

Back to Bug 1767292 Comment 13