API "block" and "unblock" functions returns unexpected output
Summary
API result of "block user" operation returns a bareword true
or false
along with the header Content-Type: application/json
. The bareword conflicts with the content-type. The existence of the bareword is undocumented. This behavior seems to be specific and unique to this set of API calls.
Steps to reproduce
- Use API to block an existing (blocked or unblocked) user.
By contrast, using the call on a non-existing user produces correct result, ie, properly-formatted JSON output.
What is the expected correct behavior?
Either:
- Return no output. (Completely correct behavior as documented)
- Return a JSON string. (But then this behavior should be documented!)
- Change output content-type header. (Not recommended. Behavior should be documented.)
Relevant logs and/or screenshots
Here, we use curl to block an existing user. Some headers omitted/edited for obvious reasons:
$ curl -v -H "Content-Type: application/x-www-form-urlencoded" -H "Private-Token: REDACTED" -X POST https://gitlab-test/api/v4/users/111/block ; echo
* About to connect() to gitlab-test port 443 (#0)
* Trying REDACTED...
* Connected to gitlab-test (REDACTED) 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: REDACTED
* start date: Jun 30 00:00:00 2016 GMT
* expire date: Jul 05 12:00:00 2019 GMT
* common name: REDACTED
* issuer: CN=TERENA SSL CA 3,O=TERENA,L=Amsterdam,ST=Noord-Holland,C=NL
> POST /api/v4/users/111/block HTTP/1.1
> User-Agent: curl/7.29.0
> Host: gitlab-test
> Accept: */*
> Content-Type: application/x-www-form-urlencoded
> Private-Token: REDACTED
>
< HTTP/1.1 201 Created
< Date: Mon, 12 Mar 2018 10:26:12 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
< Cache-Control: max-age=0, private, must-revalidate
< Content-Length: 5
< Content-Type: application/json
< Etag: W/"68934a3e9455fa72420237eb05902327"
< Vary: Origin
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Request-Id: 4ebc066a-6887-4a8a-943a-68abcd177b54
< X-Runtime: 0.011139
<
* Connection #0 to host gitlab-test left intact
true
If we repeat the operation, the results are similar with the following output:
false
When making the call on a non-existing user, the correct behavior is seen:
< HTTP/1.1 404 Not Found
< Date: Mon, 12 Mar 2018 10:38:42 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
< Cache-Control: no-cache
< Content-Length: 32
< Content-Type: application/json
< Vary: Origin
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Request-Id: f65d1b48-e3bc-4eab-8f30-e477cbf51367
< X-Runtime: 0.015897
<
* Connection #0 to host gitlab-test left intact
{"message":"404 User Not Found"}
Results of GitLab environment info
-
Prior issues checked before filing.
-
gitlab-ce-10.4.4-ce.0.el7.x86_64
-
Info environment as below, with hostname redacted:
# sudo gitlab-rake gitlab:env:info
System information
System:
Current User: git
Using RVM: no
Ruby Version: 2.3.6p384
Gem Version: 2.6.13
Bundler Version:1.13.7
Rake Version: 12.3.0
Redis Version: 3.2.11
Git Version: 2.14.3
Sidekiq Version:5.0.5
Go Version: unknown
GitLab information
Version: 10.4.4
Revision: 1d22950
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL: <REDACTED>
HTTP Clone URL: <REDACTED>/some-group/some-project.git
SSH Clone URL: git@<REDACTED>:some-group/some-project.git
Using LDAP: yes
Using Omniauth: no
GitLab Shell
Version: 5.11.0
Repository storage paths:
- default: /mnt/data/sameersbn/gitlab/repositories
Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks
Git: /opt/gitlab/embedded/bin/git