Hi team,

We’re seeing pgutil uploads of large files semi-fail over HTTPS (behind a reverse proxy), while the same uploads succeed over HTTP (direct to ProGet).

Uploading a 9.2 gb file over HTTPS, the transfer hits 100% in 3 min, then after a 2 min consolidation, pgutil reports “operation cancelled.” The asset becomes present in ProGet in both cases, but that failure prevents us from setting metadata straight after in our CI/CD pipelines.

A list of tests done:

• HTTP (bypassing reverse proxy/WAF), same file completes and metadata can be set.

• Zipped version of the file (approx 4 gb) also fails over HTTPS but when using --partsize=1000 succeeds for this 4 gb file.

• --partsize=2000,1000 and 50 on the 9.2 gb file fails.

• Direct curl PUT of the same 9.2 gb file to HTTPS succeeds.

• 8 gb dummy file also fails over HTTPS.

• 4 gb ISO file uploads fine to HTTPS.

This suggest there might be something specific about how pgutil handles large, long requests along with the step that consolidates the asset. Is there recommended guidance for pgutil with very large assets.

This is pgutil v2.1.13 running the proget server on docker container using compose.

Logs show that we aren’t getting the final 200 response when it fails:

Request starting HTTP/1.1 POST http://<proget-server>/endpoints/test/content/testfile?id=7fbe72d4b20b4492a146e93cd26be868&multipart=complete - - 0
Running Feed Replication...
Feed Replication completed.
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 POST http://<proget-server>/endpoints/test/content/testfile?id=7fbe72d4b20b4492a146e93cd26be868&multipart=complete - 200 0 - 8064.5135ms

Thanks! Just did more investigation to figure out it seems to a be WAF issue.

Hi team,

I’ve run into an issue with pgutil when trying to get metadata for assets which have file names contain spaces, where We are using Proget v2025.8 and pgutil v2.1.13, and this is being run on CMD on windows.

Running something like this works fine:

pgutil assets metadata get --path=metadata-test/v1/file1.txt --feed=Test

However, when I run something like this (with or without quotes):

pgutil assets metadata get --path="metadata-test/v1/1 - Normal.txt" --feed=Test

I get this without quotes:

unexpected argument: -
unexpected argument: normal.txt

and this with quotes:

'<' is an invalid start of a value. Path: $ | LineNumber: 1 | BytePositionInLine: 0.

I can see the file and metadata existing on proget, but it looks like pgutil isn’t correctly handling paths with spaces when passing them through to the ProGet API.

Could we get a fix for this?

Thanks,
Manish

Hi Team,
Here is an example of the page I would like to download the Conan package from:

It would be handy if we had a link somewhere for each project ID to download the associated package.

Thanks,
Manish

Hi team,

We're encountering a problem with the conan upload command to our ProGet (2025) Conan remote.

When we try to force re-upload an existing package using --force, we receive a several of 404 Client Error messages from ProGet when uploading files like conan_export.tgz, conan_sources.tgz, and conanfile.py. The command gives us a ConanException.

So we see that ProGet reports that the package already exists (in the server so forcing an upload):

boost/1.88.0: Recipe 'boost/1.88.0#b471bc5106b868d250cc39fec7411f2e' already in server, forcing upload
...
boost/1.88.0: Package 'boost/1.88.0#b471bc5106b868d250cc39fec7411f2e:da39a3ee5e6b4b0d3255bfef95601890afd80709#a7577c828425a7737edc52feef1817ca' already in server, forcing upload

However, Conan fails to upload as ProGet returns 404 errors on the expected v2 file endpoints:

HttpRequest: put: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/boost/1.88.0/_/_/revisions/.../files/conan_export.tgz
WARN: network: 404 Client Error: Not Found
...
ERROR: Error uploading file: conan_export.tgz, '404 Client Error: Not Found'

This is using the --force flag which should allow for overwriting files?

It might be the case that ProGet might be internally inconsistent? It knows about the recipe revision but the actual file blobs is missing, or is blocking us from overwriting with the uploads.

There is the possibility that it could be due to an earlier corrupted/incomplete upload, so could you confirm if ProGet should allow overwrites via Conan --force? Also, is there a known issue exists where metadata is present but backing files are missing? Finally, is there a cleanup or repair process available on ProGet to fix recipe in these broken states?

Let me know if you need more details/logs.

Thanks,
Manish

@stevedennis

By default the command operate in the local cache, but with the -r=remote argument it removes artifacts from the server.
Ref: https://docs.conan.io/2/reference/commands/remove.html

Hi @stevedennis,

Running conan remove freetype/2.13.2:* -r=ccdc-3rdparty-conan-2 -c -vvv we get:

HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v1/ping
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/search
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/0b9eabda69d299e0c26d9c8317ddd1621897aa07/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/2bc290d37f8ba2643b676474fd64176f8b8de109/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/2c78a73f698fca3c09a1748a63533228464ad95e/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/330feb85e7c7f73d79b8dcd7d66b0dfcb300d055/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/43faaf581cf6a121854a451651cf2ff235f19f7c/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/56ab506ea707052770ee3fe2c74d207e03eb913b/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/5a368093f9a03ee939b6113024e4e050e0b8ab85/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/824d26f8edc07cf9d12c6e3a7bcc11c9ce0005e9/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/8465556e8df301d7ad4d45939533bd110dc4fc9f/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/871fc4926cbe6ce3b4b4042931c0b98e1ed1553c/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/8fab62d98251e0c58e525e58a5ddbc9d03762335/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/bab1ebe447bc8c2837e705948cb15e08d1d7c49f/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/c47e9d1a66bc77b47abc78dfebcae9d0b554d34b/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/d87280ec3b4af24f27d50d5e0df28450bce31aea/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/e0458180222f4e39fcff2bfa680bfa6468ca7198/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/users/check_credentials
HttpRequest: delete: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/0b9eabda69d299e0c26d9c8317ddd1621897aa07/revisions/5af71bb11e7691ed2a1d95bf2156b5f8

With the -p ie. conan remove freetype/2.13.2:* -p os=Linux -r=ccdc-3rdparty-conan-2 -c -vvv we get:

HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v1/ping
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/search
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/43faaf581cf6a121854a451651cf2ff235f19f7c/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/d87280ec3b4af24f27d50d5e0df28450bce31aea/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/e0458180222f4e39fcff2bfa680bfa6468ca7198/revisions
HttpRequest: get: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/users/check_credentials
HttpRequest: delete: https://proget.ccdc.cam.ac.uk/conan/ccdc-3rdparty-conan/v2/conans/freetype/2.13.2/_/_/revisions/012f2e384087877914dbac626c3978e2/packages/43faaf581cf6a121854a451651cf2ff235f19f7c/revisions/b698aa74ca56cfc1edeca40d1939a310

In both cases we get the same error:

Traceback (most recent call last):
  File "/mnt/f/conan2/venv/lib/python3.10/site-packages/conan/cli/cli.py", line 193, in run
    command.run(self._conan_api, args[0][1:])
  File "/mnt/f/conan2/venv/lib/python3.10/site-packages/conan/cli/command.py", line 179, in run
    info = self._method(conan_api, parser, *args)
  File "/mnt/f/conan2/venv/lib/python3.10/site-packages/conan/cli/commands/remove.py", line 119, in remove
    conan_api.remove.package(pref, remote=remote)
  File "/mnt/f/conan2/venv/lib/python3.10/site-packages/conan/api/subapi/remove.py", line 50, in package
    app.remote_manager.remove_packages([pref], remote)
  File "/mnt/f/conan2/venv/lib/python3.10/site-packages/conan/internal/rest/remote_manager.py", line 210, in remove_packages
    return self._call_remote(remote, "remove_packages", prefs)
  File "/mnt/f/conan2/venv/lib/python3.10/site-packages/conan/internal/rest/remote_manager.py", line 269, in _call_remote
    return self._auth_manager.call_rest_api_method(remote, method, *args, **kwargs)
  File "/mnt/f/conan2/venv/lib/python3.10/site-packages/conan/internal/rest/auth_manager.py", line 60, in call_rest_api_method
    ret = getattr(rest_client, method_name)(*args, **kwargs)
  File "/mnt/f/conan2/venv/lib/python3.10/site-packages/conan/internal/rest/rest_client.py", line 81, in remove_packages
    return self._get_api().remove_packages(prefs)
  File "/mnt/f/conan2/venv/lib/python3.10/site-packages/conan/internal/rest/rest_client_v2.py", line 385, in remove_packages
    raise get_exception_from_error(response.status_code)(response.text)
conan.internal.errors.RequestErrorException: expected revision after package id. [Remote: ccdc-3rdparty-conan-2]

Hi Team,

We've been evaluating the new Conan feed UI in the 2025 version of ProGet and had some feedback to provide.

Multiple rows for same version

In the previous version of the ProGet UI, each package version (e.g. zlib/1.3.1) was shown as a single row, with a summary of downloads. In the new UI, the same version appears multiple times, once per package variant:

This makes it harder to quickly view the overall usage or find the version we’re interested in.

Would it possible to show the older summary view? Perhaps have an option to toggle between the classic view?

Missing Package Metadata

In the new file level view:

each .tgz file is listed without any metadata e.g. OS/arch, options, profiles or complier settings etc.

This makes it difficult to know which package is which without downloading. Showing the metadata in the column would help make it easier to inspect.

There seems to be an issue with ProGet's Conan V2, where the conan remove command fails when using the -p profile filter.

example:
conan remove freetype/2.13.2:* -p os=Linux -r=ccdc-3rdparty-conan-2 --dry-run -c

gives:

Remove summary: ccdc-3rdparty-conan-2 freetype/2.13.2#012f2e384087877914dbac626c3978e2: Removed binaries: ['43faaf581cf6a121854a451651cf2ff235f19f7c', 'd87280ec3b4af24f27d50d5e0df28450bce31aea', 'e0458180222f4e39fcff2bfa680bfa6468ca7198']

Whereas the non dry-run:

conan remove freetype/2.13.2:* -p os=Linux -r=ccdc-3rdparty-conan-2 -c

gives us:

ERROR: expected revision after package id. [Remote: ccdc-3rdparty-conan-2]

We reached out to the Conan team, where they tested and confirmed it should be working fine from their end, see thread: https://github.com/conan-io/conan/issues/18553

Could you investigate and confirm if this is a known limitation or bug?

Thanks!

Hi @stevedennis,

You're right, they are blobs, however the directory structure itself is still has value and reflects the layout of the package e.g. name/version/export/package etc.

Here's a screenshot of what we see:

So even though some of the folder/files have hashed names, the overall structure with export/,
package/, and files like conaninfo.txt are quite useful when trying to inspect/debug packages.

Something like this in the ProGet web UI would be much appreciated.

Thanks!