### 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 ```