gitlab-api-http-redirect-post-downgrade

Answer

Root cause (confirmed in source, not just folklore). The readydedis nginx front does the standard return 301 https://$host$request_uri;. When a client POSTs to http://…, urllib's HTTPRedirectHandler.redirect_request (Python 3.14.4, verified) converts the method to GET on 301/302/303 and drops Content-Type/Content-Length:

# urllib/request.py
return Request(newurl,
               method="HEAD" if m == "HEAD" else "GET",   # POST -> GET !
               headers=newheaders,                        # content headers stripped
               ...)

So POST /api/v4/projects/:id/merge_requests silently became GET /api/v4/projects/…/merge_requests, which returns the MR list, and resp["iid"] on a list raised TypeError: list indices must be integers. Only 307/308 preserve the method — nginx's 301 does not. I also verified requests does the same downgrade (see Evidence).

Fix 1 — primary: use https:// directly in all API client scripts so no redirect ever occurs:

import json, urllib.request

GITLAB = "https://gitlab.readydedis.example"   # was "http://..."  ← the fix

def create_mr(token: str) -> dict:
    url = f"{GITLAB}/api/v4/projects/1/merge_requests"
    body = json.dumps({"source_branch": "fix/https",
                       "target_branch": "main",
                       "title": "fix: use https"}).encode()
    req = urllib.request.Request(url, data=body, method="POST", headers={
        "PRIVATE-TOKEN": token, "Content-Type": "application/json"})
    with urllib.request.urlopen(req) as resp:
        assert resp.status == 201, resp.status
        return json.loads(resp.read())          # dict {"iid": ...} — MR created

Same rule for requests/httpx: point them at the https:// origin (requests.post(..., verify=...) with the real cert); never at the http:// front.

Fix 2 — belt-and-braces: a method-preserving redirect handler in case any client still receives a 301 (works for urllib; for requests you'd have to disable redirect-following and handle it manually, which is why Fix 1 is preferred):

class KeepPostOn301(urllib.request.HTTPRedirectHandler):
    def redirect_request(self, req, fp, code, msg, headers, newurl):
        new = super().redirect_request(req, fp, code, msg, headers, newurl)
        if new is not None and code == 301:
            new.method = req.get_method()               # keep POST
            new.data = req.data                         # keep body
            new.add_unredirected_header("Content-Type", "application/json")
        return new

opener = urllib.request.build_opener(KeepPostOn301)

Fix 3 — ops: never trust a smoke result without checking the port owner. The stale :8083 demo orphan (a bash -lic wrapper spawned by the gateway) kept answering smoke curls with old behavior, masking the fresh binary since T103:

# pre-smoke gate
ss -tlnp | grep ':8083'                 # -> users:(("python3",pid=112,...)) 
ps -o pid,ppid,lstart,cmd -p 112        # is this the binary you just built? if not:
kill 112                                # kill the orphan
ss -tlnp | grep ':8083' || echo "port free — smoke is trustworthy"