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

  1. 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:

  1. Return no output. (Completely correct behavior as documented)
  2. Return a JSON string. (But then this behavior should be documented!)
  3. 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
Edited by otheus