User-agent header not set in webhook calls
Summary
Looking at the HTTP headers from a gitlab webhook call, the User-Agent header is not set.
Steps to reproduce
(1) create a simple script on a webserver to capture and log HTTP headers from an incoming request. For example, in PHP:
<?php
$result = print_r( getallheaders(), true );
file_put_contents( __DIR__ . '/headers.txt', $result );
(2) in the integrations section of a repository's settings, add a webhook in GitLab to call that script
(3) click test
for that webhook
(4) look at headers recorded by script
What is the current bug behavior?
The following headers are sent with the request:
[Authorization] =>
[Host] => *****
[X-Forwarded-Host] => *****
[X-Forwarded-Server] => *****
[Forwarded-Request-Uri] => /testscript.php
[Https] => off
[X-Forwarded-Proto] => http
[X-Forwarded-Ssl] => off
[Connection] => close
[Content-Length] => 3015
[Content-Type] => application/json
[X-Gitlab-Event] => Push Hook
What is the expected correct behavior?
There should also be a User-Agent header such as:
[User-Agent] => GitLab 9.2
Why this is an issue
RFC7231 states that A user agent SHOULD send a User-Agent field in each request
, so formally there is no requirement to do so. However, at least one popular piece of anti-spam software (WP-Spamshield for WordPress) blocks all calls to the site where the user-agent header is not set. To quote one of the plugin authors:
As a matter of basic protocol, all HTTP requests should provide an identifying User-Agent. Having one does not mean a resource is trustworthy, but NOT having one almost always means a resource is not trustworthy.
Since RFC7231 states that the User-Agent header should be set, and http clients which don't set it are often bad bots, would it not be sensible to set the header?