CLI cannot handle server response #2618
Description
Activity
Apologies for the "necrobump" and the @nejch -bump 😅
I am having the same issue in gitlab --version 4.4.0.
$ gitlab --debug project-merge-request-discussion list --project-id ./. --mr-iid 14254 DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): gitlab.....com:443 DEBUG:http.client:send: b'GET /-/profile/personal_access_tokens/api/v4/user HTTP/1.1\r\nHost: gitlab.....com\r\nUser-Agent: python-gitlab/4.4.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nContent-type: application/json\r\nPRIVATE-TOKEN: [MASKED]\r\n\r\n' DEBUG:http.client:reply: 'HTTP/1.1 302 Found\r\n' DEBUG:http.client:header: Server: nginx DEBUG:http.client:header: Date: Wed, 06 Mar 2024 10:15:56 GMT DEBUG:http.client:header: Content-Type: text/html; charset=utf-8 DEBUG:http.client:header: Content-Length: 113 DEBUG:http.client:header: Connection: keep-alive DEBUG:http.client:header: Cache-Control: no-cache DEBUG:http.client:header: Content-Security-Policy: DEBUG:http.client:header: Location: https://gitlab.....com/users/sign_in DEBUG:http.client:header: Permissions-Policy: interest-cohort=() DEBUG:http.client:header: Set-Cookie: _gitlab_session=123; path=/; expires=Wed, 06 Mar 2024 12:15:56 GMT; secure; HttpOnly; SameSite=None DEBUG:http.client:header: X-Content-Type-Options: nosniff DEBUG:http.client:header: X-Download-Options: noopen DEBUG:http.client:header: X-Frame-Options: SAMEORIGIN DEBUG:http.client:header: X-Permitted-Cross-Domain-Policies: none DEBUG:http.client:header: X-Request-Id: 01HR9M6EQ612FW242WQ9R3Q31B DEBUG:http.client:header: X-Runtime: 0.036455 DEBUG:http.client:header: X-Ua-Compatible: IE=edge DEBUG:http.client:header: X-Xss-Protection: 1; mode=block DEBUG:http.client:header: Strict-Transport-Security: max-age=63072000 DEBUG:http.client:header: Referrer-Policy: strict-origin-when-cross-origin DEBUG:urllib3.connectionpool:https://gitlab.....com:443 "GET /-/profile/personal_access_tokens/api/v4/user HTTP/1.1" 302 113 DEBUG:http.client:send: b'GET /users/sign_in HTTP/1.1\r\nHost: gitlab.....com\r\nUser-Agent: python-gitlab/4.4.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nPRIVATE-TOKEN: [MASKED]\r\nCookie: _gitlab_session=123\r\n\r\n' DEBUG:http.client:reply: 'HTTP/1.1 200 OK\r\n' DEBUG:http.client:header: Server: nginx DEBUG:http.client:header: Date: Wed, 06 Mar 2024 10:15:57 GMT DEBUG:http.client:header: Content-Type: text/html; charset=utf-8 DEBUG:http.client:header: Transfer-Encoding: chunked DEBUG:http.client:header: Connection: keep-alive DEBUG:http.client:header: Vary: Accept-Encoding DEBUG:http.client:header: Cache-Control: max-age=0, private, must-revalidate DEBUG:http.client:header: Content-Security-Policy: DEBUG:http.client:header: Etag: W/"284a8b1c3b1ef3b933248c22518c7867" DEBUG:http.client:header: Permissions-Policy: interest-cohort=() DEBUG:http.client:header: Set-Cookie: preferred_language=en; path=/; Secure; SameSite=None DEBUG:http.client:header: Set-Cookie: _gitlab_session=123; path=/; expires=Wed, 06 Mar 2024 12:15:57 GMT; secure; HttpOnly; SameSite=None DEBUG:http.client:header: Vary: Accept DEBUG:http.client:header: X-Content-Type-Options: nosniff DEBUG:http.client:header: X-Download-Options: noopen DEBUG:http.client:header: X-Frame-Options: SAMEORIGIN DEBUG:http.client:header: X-Permitted-Cross-Domain-Policies: none DEBUG:http.client:header: X-Request-Id: 01HR9M6ESETMSCH66NRRVZNX9Q DEBUG:http.client:header: X-Runtime: 0.064135 DEBUG:http.client:header: X-Ua-Compatible: IE=edge DEBUG:http.client:header: X-Xss-Protection: 1; mode=block DEBUG:http.client:header: Strict-Transport-Security: max-age=63072000 DEBUG:http.client:header: Referrer-Policy: strict-origin-when-cross-origin DEBUG:http.client:header: Content-Encoding: gzip DEBUG:urllib3.connectionpool:https://gitlab.....com:443 "GET /users/sign_in HTTP/1.1" 200 None Attempted to initialize RESTObject with a non-dictionary value: <Response [200]> This likely indicates an incorrect or malformed server response.
idk why would I need to sign_in 😕 private_token = helper: does return the correct token
Any ideas?
@stdedos in your case, you seem to have the wrong base URL. /-/profile/personal_access_tokens/api/v4/user in the initial GET call looks suspicious as that's a web endpoint and not for the v4 API. did you make sure it's just set to https://gitlab.com or left out (maybe there's an environment variable is interfering)?
And I suspect the same thing might be happening in the original post, but our CLI might not be the most informative with the malformed response error (e.g. if it's returning some HTML because the user hits the web browser URL instead of the API endpoints).
Yeap 😕 That's it
Can you please make gitlab.Gitlab a bit more strict it what it accepts? And/or check early if "it's valid" or not?
... do you want a new issue, or re-use this one?
a bit more strict it what it accepts? And/or check early if "it's valid" or not?
If you mean the URLs, I don't think we can as people can serve GitLab at arbitrary endpoints (e.g. https://company.com/my-gitlab, https://company.com/apps/-/gitlab/ - silly example but you get the idea). So it's hard to tell whether a URL is a GitLab base URL or a project URL (which shouldn't be used).
We check if we can authenticate using gl.auth() which I think should already fail here. I'd say best to expose a bit more info if the returned object is a Response perhaps?
So it's hard to tell whether a URL is a GitLab base URL or a project URL (which shouldn't be used).
Yeah, I have done that mistake multiple times 😅
I'd say best to expose a bit more info if the returned object is a Response perhaps?
Sure, but - I have no idea what. That obviously looks wrong:
DEBUG:http.client:send: b'GET /users/sign_in HTTP/1.1\r\nHost: gitlab.....com\r\nUser-Agent: python-gitlab/4.4.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nPRIVATE-TOKEN: [MASKED]\r\nCookie: _gitlab_session=123\r\n\r\n' DEBUG:http.client:reply: 'HTTP/1.1 200 OK\r\n'
but, in the context of
DEBUG:http.client:send: b'GET /-/profile/personal_access_tokens/api/v4/user HTTP/1.1\r\nHost: gitlab.....com\r\nUser-Agent: python-gitlab/4.4.0\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nContent-type: application/json\r\nPRIVATE-TOKEN: [MASKED]\r\n\r\n' DEBUG:http.client:reply: 'HTTP/1.1 302 Found\r\n'
"it's not exactly wrong".
- added a commit that references this issue on Jul 12, 2024
- added a commit that references this issue on Jul 12, 2024
This issue was closed because it has been marked stale for 15 days with no activity. If this issue is still valid, please re-open.
This issue was marked stale because it has been open 60 days with no activity. Please remove the stale label or comment on this issue. Otherwise, it will be closed in 15 days.
This issue was closed because it has been marked stale for 15 days with no activity. If this issue is still valid, please re-open.
#NotStale? 😕
- locked as resolved and limited conversation to collaborators on Oct 20, 2025
Description of the problem, including code/CLI snippet
gitlab -c ./gitlab-cli.cfg project-merge-request get --iid 98765 --project-id 12345
with config file content being
results in
Expected Behavior
Since I can successfully interact with the same server programmatically from Python (i.e. I am getting a valid server JSON response) I suspect this is a problem of the CLI.
The server response is 200 this typically indicates OK. So it will have sent some payload back.
I expect identical behaviour of package and CLI.
Actual Behavior
Specifications