[Feature Request / out-of-spec regression] Relative URIs starting with .. no longer work in metadata files

[dragonmaus]

In pre-0.5.0 versions, the HTTP resolver would "correctly" parse relative URIs starting with ../. Version 0.5.0 throws an IllegalArgumentException when it encounters such entries.

Example:
http://example.com/packwiz-repo/config/Adorn.json5.toml

name = "config/Adorn.json5"
filename = "Adorn.json5"
side = "both"

[download]
url = "../files/config/Adorn.json5"
hash-format = "sha256"
hash = "cd7e9a0b0248131ee7923eb63a9a61f41efbe57ee6b0919c003693ecba52a6ae"

v0.4.3 resolves url to http://example.com/packwiz-repo/files/config/Adorn.json5
v0.5.0 throws java.lang.IllegalArgumentException: Expected URL scheme 'http' or 'https' but no scheme was found for ../fil...

[Dakedres]

Would also like to note that it would be nice if files refrenced by relative downloads were still hosted, even if they were targeted by the .packwizignore, so we could keep all of our pack in a single directory and not have users downloading files they're not using.

[dragonmaus]

Would also like to note that it would be nice if files refrenced by relative downloads were still hosted, even if they were targeted by the .packwizignore, so we could keep all of our pack in a single directory and not have users downloading files they're not using.

This is the responsibility of whatever method you use to upload the files or otherwise set them up on the host. Packwiz doesn't have anything to do with what files are or are not hosted.

[Dakedres]

I'm referring to packwiz serve, it does not serve files included in your .packwizignore