Page MenuHomePhabricator

API "Content-Type" header warning
Closed, ResolvedPublic

Description

This ticket was files during bridge development but the challenge is one of the API/backend request processing, not depended on a particular client.

In my dev system, a mediawiki-docker-dev, I'm seeing a warning in the API response to a wbeditentity call (in this example bridge's saving of an entity saving).

A POST request was made without a "Content-Type" header. This does not work reliably.Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Strange, I don’t see that warning on my system, and the content-type is set (application/x-www-form-urlencoded; charset=UTF-8). And this should be done by mw.Api, not us, right?

And this should be done by mw.Api, not us, right?

Right. The header is sent, the problem is on the receiving end - i.e. this was discovered during bridge development but has nothing to do with bridge itself.

On my dev system (somewhat dated https://github.com/addshore/mediawiki-docker-dev/)
apache_request_headers is not defined
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/05e0582/includes/WebRequest.php#1075

but the alternative code path to determine the headers
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/05e0582/includes/WebRequest.php#1082
(almost) only extracts "HTTP_"-prefixed entries from $_SERVER - content type is not one for them.

Consequently, the Content-Type can not be detected and the warning happens
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/05e0582/includes/api/ApiMain.php#1538

Ironically, we knew that once (mind the user name)
https://www.php.net/manual/en/reserved.variables.server.php#110763

Interestingly, there is a polyfill in mediawiki-vendor that knows how to do it right
https://github.com/wikimedia/mediawiki-vendor/blob/71024a7/ralouphie/getallheaders/src/getallheaders.php#L15

Its presence also explains why getallheaders() is available on my system even though the docs say it's "an alias for apache_request_headers()".

Change 580870 had a related patch set uploaded (by Pablo Grass (WMDE); owner: Pablo Grass (WMDE)):
[mediawiki/core@master] DNM: WebRequest: one way to extract headers from HTTP request

https://gerrit.wikimedia.org/r/580870

Pablo-WMDE renamed this task from Bridge save API request - "Content-Type" header warning to API "Content-Type" header warning.Mar 25 2020, 8:11 AM
Pablo-WMDE updated the task description. (Show Details)

Moving this to wmde-wikidata-tech as it does not really belong on the bridge board.

I'm reluctant to put the word "development" in the title. It does surface in dev in our case but, according to the hypothesis in https://gerrit.wikimedia.org/r/580870, it could happen in (non-wikimedia-infrastructure) prod environments just as well.

@Pablo-WMDE what's the priority for this task?

@AMooney This likely should go to external code review for Clinic Duty but tagging it cpt so it gets triaged.

Change 580870 abandoned by Pablo Grass (WMDE):
DNM: WebRequest: one way to extract headers from HTTP request

Reason:
tl;dr Defect identified; needs implementation in line with standards

Thanks for the reference to I197366ef6f490bb7676c21d99568e4ffd229673b and Anomie acknowledging (that's how I understood it) that this PoC indeed complements the use case bba1a0f addresses.
I interpret both signals as indicating that a change to make Content-Type generally available in the list of headers is indeed useful, needed even.

I am not attached to any particular way of implementing a solution. The way RequestFromGlobals (redundantly) implements header processing and the fact that it was recently touched to add Content-Type handling there but core's process handling remained unchanged to me suggests that "libarization", reuse of code, (the approach I suggested, from a 3rd party even) is not in quite in line with general practice in core development.

T245535 received some tagging ("Core Platform Team Workboards") so it's probably fair to assume the challenge is now acknowledged and may eventually be addressed by those in the know.

https://gerrit.wikimedia.org/r/580870

@WDoranWMF Thanks for getting back to me. I am not the right person to triage core tickets, I guess.
In the scenario I know it does not cause a defect, only a warning. It is thinkable that the inability to detect the Content-Type impairs certain features but no such case is known to me.
For me it happens in a (non-production) environment with a setup which does not mirror WMF infrastructure (key difference: the function apache_request_headers() is not available).
If I had to guess: "lowest priority".

I don’t quite understand what happened here… we had a fix ready, which looked straightforward to me, but then that was abandoned and now this task is probably going to languish at Lowest priority for years?

Change 580870 restored by Pablo Grass (WMDE):
DNM: WebRequest: one way to extract headers from HTTP request

https://gerrit.wikimedia.org/r/580870

Change 580870 merged by jenkins-bot:
[mediawiki/core@master] WebRequest & RequestFromGlobals: get HTTP headers in one way

https://gerrit.wikimedia.org/r/580870