Page MenuHomePhabricator

VRS should accept user-agent information and pass it along
Closed, InvalidPublic

Description

VE, CX, Flow all go through VRS and 'grep headers includes/libs/virtualrest/*' shows that user-agent is not being set there. This means that RESTBase then passes a RESTBase/WMF header in the user-agent string to Parsoid (In T129752#2118608, @mobrovac says that RESTBase adds that user agent string if the client doesn't provide any user-agent header).

So, if VRS can accept a user-agent param, then clients can pass RESTBase user-agent info via VRS and RESTBase would then pass that along to Parsoid which would simplify log analysis and attributing requests to the upstream clients that generated those requests.

Event Timeline

RestbaseVirtualRESTService does not mangle the headers at all, but lets them pass through. It [only alters the cookie header](https://github.com/wikimedia/mediawiki/blob/c339459eb3ee100c0abda4ebf7e4266f7b3d58bd/includes/libs/virtualrest/RestbaseVirtualRESTService.php#L96) if so set in the configuration.

Judging by the looks of it, all that VRS users need to do is actually set the UA header. Close this task as invalid?

Sounds like this already works

santhosh triaged this task as Medium priority.
santhosh subscribed.

Both CX and VE are setting user-agent header in requests.

But, I still see "wikimedia/multi-http-client v1.0" as the user agent for logs in logstash for all the requests.
That comes from the default user-agent value of core/inculdes/lib/MultiHttpClient.php
Is the header value set getting lost somewhere?

@santhosh From what I can tell, this is handled properly in the MW Core's HTTP Client. In the CX extension, however, there is bug in requestRestbase(): you set the header, but never associate the header array to the request object itself, so the Accept and User-Agent headers never actually make it through.