mip: can't resolve relative paths `../` and `requests` raises `Unsupported protocol`

[o-murphy]

Summary

mip package installer raises ValueError: Unsupported protocol when processing relative paths containing ../ segments. While the mip specification and common usage in micropython-lib imply support for relative URL resolution, the current implementation of requests (or the underlying URL parser) in the Unix port appears to reject URLs containing directory traversal segments.

Environment

• MicroPython version: v1.28.0
• Port: Unix (GCC 15.2.0)

>>> import requests
>>> requests.__version__
'0.10.2'
>>> import mip
>>> mip.__version__
'0.4.2'

Reproduction

When a package.json file uses a relative path to reference a file outside the current directory, the mip installer performs a concatenation that results in a URL containing ../.
package.json:

{
    "version": "0.1.0",
    "urls": [
        ["file.py", "../subdir/file.py"]
    ]
}

Execution:

import mip
mip.install("https://raw.githubusercontent.com/owner/repo/branch/subdir/package.json")

Observed Result:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "mip/__init__.py", line 1, in install
  ...
  File "requests/__init__.py", line 75, in request
ValueError: Unsupported protocol:

Real-world example

./micropython -c "import requests; requests.get('https://raw.githubusercontent.com/ballistics-lab/micropython-bclibc/installer/natmod/../src/tiny_bclibc.py')"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "requests/__init__.py", line 205, in get
  File "requests/__init__.py", line 190, in request
  File "requests/__init__.py", line 75, in request
ValueError: Unsupported protocol: 

It still reachae with python3

python3 -c "import requests; p
rint(requests.get('https://raw.githubusercontent.c
om/ballistics-lab/micropython-bclibc/installer/nat
mod/../src/tiny_bclibc.py').ok)"
True

Urllib

python3 -c "import urllib.req
uest; print(urllib.request.urlopen('https://raw.gi
thubusercontent.com/ballistics-lab/micropython-bcl
ibc/installer/natmod/../src/tiny_bclibc.py').getco
de() == 200)"
True

The url still reachable with web browser: https://raw.githubusercontent.com/ballistics-lab/micropython-bclibc/installer/natmod/../src/tiny_bclibc.py

Additional Context

Standard mip behavior (as seen in micropython-lib/mip) relies on concatenating a base_url with relative paths defined in the JSON.
Previously, this mechanism handled relative paths correctly. For instance, packages that use standard relative referencing within the same directory tree or logically sound paths typically resolve without issues. An example of a valid relative URL resolution that is expected to work is:

• Base: https://raw.githubusercontent.com/micropython/micropython-lib/master/package/
• Relative: subdir/file.py
• Resolved: https://raw.githubusercontent.com/micropython/micropython-lib/master/package/subdir/file.py
  The current issue specifically triggers when the path contains ../ (e.g., ../src/file.py). It appears that the request validator now considers the presence of .. in a URL string as malformed or an unsupported protocol, breaking the core functionality of mip for packages that do not use a flat file structure.

[o-murphy]

The reason why this is a problem is that if we want to distribute prebuilt native mpy module (natmod) for different target arch(es), creating separate branch/tag for each version and micropython port is poor variant and also storing single package.json in the repo root is not working for this case.

The expected repo structure might be something like

.
├── src/                        # Shared C + Python source
│   ├── mylib_mp.c        # MicroPython C extension (natmod + usermod)
│   └── mylib.py          # Python API wrapper (frozen into firmware)
│
├── natmod/                     # Native module (.mpy) build
│   └── Makefile                # make x64 / armv6m / esp32c3 / …
│
├── usermod/                    # Usermod (baked-into-firmware) build
│   ├── Makefile                # make x64 / armhf / mipsel / rp2040 / …
│   ├── micropython.mk          # Picked up by py.mk via USER_C_MODULES
│   ├── micropython.cmake       # CMake entry point for RP2040 / pico-sdk
│   ├── manifest.py             # Freezes mylibc.py into firmware (release)
│   └── ci/micropython-run.ts   # rp2040js emulator test runner
│
├── version.h.in                # Version template (filled by Makefile)
└── LICENSE 

And branch with prebuild modules

.
├── rp2/
│   ├── package.json  # for the target
│   └── _mylib.mpy    # natmod for the target
│
├── unix/
│   ├── package.json  # for the target
│   └── _mylib.mpy    # natmod for the target
│
└── mylib.mpy         # shared bytecode wrapper

The package.json will looks like

{
    "version": "0.1.0",
    "urls": [
        ["mylib.py", "../src/mylib.py"],
        ["_mylib.py", "_mylib.py"]
    ]
}

[o-murphy]

So after few tests I got this

localhost:~# micropython -c "import socket, ssl; s = socket.socket();s.connect(socket.getaddrinfo('google.com', 443)[0][-1]); ssl.wrap_socket(s,server_hostname='google.com').close(); print('SSL OK')"
SSL OK

localhost:~/usermod# ./micropython -c "import socket, ssl; host='https://raw.githubusercontent.com/b
allistics-lab/micropython-bclibc/installer/src/tiny_bclibc.py'; port=443; s = socket.socket(); s.con
nect(socket.getaddrinfo(host, port)[0][-1]); ssl_s = ssl.wrap_socket(s, server_hostname=host); ssl_s.write(b'GET / HTTP/1.0\r\nHost: ' + host.encode() + b'\r\n\r\n'); print(ssl_s.readline()); ssl_s.cl
ose()"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [addrinfo error -2]

So the problem is in ssl stack and there 3 ways to fix it:

• Fix the ssl stack entirely
• Add workaround in requests module
• Add workaround in mim module