### Bug description

I'm facing quite a series of challenges installing extensions. My specific use case is to distribute an extension that is hosted on a private enterprise GitLab server. This introduces a few challenges that I haven't been able to work through.

For now, my solution is to clone the extension as a submodule and symlink it into the `_extensions` directory, which is neither intuitive nor convenient (and seems to have its own issues with some file resolution, but that's for a separate issue). 

## `github` hostname is hardcoded in extension host resolvers

First and foremost, even though the docs describe and give an example of installing an archive from GitLab, this doesn't appear to work. I copied the contents of [`quarto-ext/fontawesome`](https://github.com/quarto-ext/fontawesome) to [`gitlab.com/dgkf/quarto-ext-test`](https://gitlab.com/dgkf/quarto-ext-test) and tried to install it using

```sh
quarto create-project quarto-test --type website
cd quarto-test
quarto install extension https://gitlab.com/dgkf/quarto-ext-test/-/archive/main/quarto-ext-test-main.zip
# Extension not found in local or remote sources
```

to no avail. Digging into the code a bit, it looks like `github.com` is hardcoded into [the resolvers](https://github.com/quarto-dev/quarto-cli/blob/0ae67eb02977732094a63958098fe8f3d0fb1408/src/extension/extension-host.ts#L56-L59).

## Resolvers assume archive urls end in `.zip`

Even if the resolvers were more agnostic to hostnames, this would not alone allow me to install extensions since a privately hosted GitLab server will require authentication. To authenticate to download a `.zip` over `https` I would need to add a `private_token` to my request:

```
curl -L "https://enterprise.gitlab.com/proj/subproj/repo/-/archive/main/repo-main.zip?private_token=$GITLAB_PAT"
```

So the resolvers would also need to handle situations where additional query parameters are provided after the file name. This also sits behind a proxy that initially redirects the request. From what I can tell the `fetch(<url>)` will default to following redirects, but it's a detail just to be conscious of if you're considering enhancements.

## Possible alternatives?

I'm not sure what your plans are for extensions management, but I would imagine you'll eventually include a manifest of extensions to allow for a simple `quarto update extensions`. In that case, private tokens would easily slip into manifest files if they are embedded in the source urls.

To help sidestep accidental credential leaking altogether, it would be great if `quarto` could handle arbitrary `.git` urls. It's much easier to handle authentication via git, and alternative hosts are much more likely to provide a consistent interface to `.git` urls over `ssh` than they are to provide `.zip` archives over `https`. Credentials are already managed and configured via `ssh`, and it would be great if `quarto` could leverage system `git` credential management while downloading extensions.

----
_OS: Running in `rocker/verse` with `quarto` updated to `1.1.189`_

```bash
FROM rocker/verse
ENV QUARTO_VERSION=latest
RUN bash /rocker_scripts/install_quarto.sh
```


### Checklist

- [X] Please include a minimal, fully reproducible example in a single .qmd file? Please provide the whole file rather than the snippet you believe is causing the issue.
- [X] Please [format your issue](https://quarto.org/bug-reports.html#formatting-make-githubs-markdown-work-for-us) so it is easier for us to read the bug report.
- [X] Please document the RStudio IDE version you're running (if applicable), by providing the value displayed in the "About RStudio" main menu dialog?
- [X] Please document the operating system you're running. If on Linux, please provide the specific distribution.
dragonstyle
2022-09-12T21:12:31Z
dgkf
bug extensions
v1.2
closed
Installing extension from archive of non-GitHub hosts not supported as described in documentation
https://github.com/quarto-dev/quarto-cli/issues/2419