We use "IP address" consistently instead of "IP", but this was never
applied to the "range" addition.
Change-Id: I02fecf0b9e6a5b90f7a24209c7a1cdce64060b23
This lets us capture some basic endpoint timing data that is
lacking now, such as upload API call time.
Change-Id: If0627e2d78d82b22ed6bdaaa0fa7fe5f20ef50b1
This matches the behavior of Special:LinkSearch, and makes it more
likely to give sensible results for non-normalized input.
Bug: T130912
Change-Id: I2f60dd48fdfc24108110a24ad41b297ece7f33df
When MediaWiki encounters an unhandled exception, the error message it produces
includes a randomly-generated token, which allows the exception details to be
looked up in the error logs. This is useful but narrow: would it not be useful
to have the ability to retrieve all log records associated with a particular
request, rather than just exception details? (Hint: yes.)
So: introduce the notion of a request-global unique ID, retrievable via
WebRequest::getRequestId(). When MediaWiki is behind Apache + mod_unique_id
(which provides the same facility) or some other software which sets a
UNIQUE_ID envvar, the value of that envvar is used as the request ID.
Otherwise, it is a randomly-generated 24-character string.
The request ID supplants exception-specific IDs; MWExceptionHandler::getLogId()
is deprecated, accordingly. The request ID is also added as an annotation to
all Monolog-processed log records, and is exposed client-side as 'wgRequestId'.
This allows developers to associate a page view with log records even when the
page view does not result in an unhandled exception. (For the WMF, I also
intend to add it as an annotation to profiling data).
The request ID is not a tracking token; it does not persist, and it is
associated with a backend request, not with a particular user or a particular
session. Like the data in the NewPP report, the request ID is designed to be
cacheable, so that if, for example, a developer notices something weird in the
HTML, s/he can associate the output with a backend request regardless of
whether the response was served from the cache or directly from the backend.
Some prior art:
* https://httpd.apache.org/docs/2.4/mod/mod_unique_id.html
* http://api.rubyonrails.org/classes/ActionDispatch/RequestId.html
* https://github.com/dabapps/django-log-request-id
* https://packagist.org/packages/php-middleware/request-id
* https://github.com/rhyselsmore/flask-request-id
Change-Id: Iaf90c20c330e0470b9b98627a0228cadefd301d1
Adds a method for getting watchlist's notification timestamps
for a batch of LinkTargets.
Bug: T129482
Change-Id: I1f84212e7879a84b34bb3b53859069fcea282bba
The problem is that ApiQuery requires the 'read' right even though
ApiQueryTokens doesn't.
So, we introduce an exception: if action=query gets only meta=tokens
(and optionally rawcontinue and indexpageids, since they don't affect
anything), no other modules and nothing in the ApiPageSet,
ApiQuery::isReadMode() will return false.
Bug: T130112
Change-Id: I83dafb0305ff0cb1fc3bac668b88b5d2022e5880
Half of the work needed for handling this logging stream was done using
the channel name "ApiRequest" and the other half was done under the name
"ApiAction". The ApiRequest naming is easier to change at this point.
Bug: T108618
Change-Id: I5797731abeba22ef6ced7c8407ee670344d35b3d
This is for batch counting of visiting watchers, following the change
made in I2868c31fc09121de381d822e8f49194e3022bb42.
Query/logic has been extracted from ApiQueryInfo.
Bug: T129482
Change-Id: Ia9a534f5edb7af3cb7bf86be358dddb5d8c259cf
Ie84e6feaa42db1bc7a1f89b56aed37dd7fe95ea4 part of them problem
with incorrect API response but if when no watchers data is
fetched (ie. due to early return in ApiQueryInfo::getWatcherInfo),
response contains "watchers": null instead of skipping "watchers"
key entirely.
Bug: T129482
Change-Id: I9cab120ec4e6a9cf4626678e45ef14ea8efc8cbc
Fixes an issue introduced in:
I5a465773599cce9f8c9e94847cede6d12282c827
The new code now returns all targets even when 0
watcher have been found.
This patch adjusts the api to expect that.
Bug: T129482
Change-Id: Ie84e6feaa42db1bc7a1f89b56aed37dd7fe95ea4
This query / logic has been extracted from
ApiQueryUserInfo.
Unit & Integration tests have also been added.
Relating to the task linked this is the last change
needed in this ApiQueryUserInfo!
Bug: T129482
Change-Id: I91aa109416c16cd1f257c9de46669e35d6fd34d7
* ApiBase::addTokenProperties() was removed (deprecated since 1.24).
* ApiBase::getFinalPossibleErrors() was removed (deprecated since 1.24).
* ApiBase::getFinalResultProperties() was removed (deprecated since 1.24).
* ApiBase::getRequireAtLeastOneParameterErrorMessages() was removed (deprecated since 1.24).
* ApiBase::getPossibleErrors() was removed (deprecated since 1.24).
* ApiBase::getRequireMaxOneParameterErrorMessages() was removed (deprecated since 1.24).
* ApiBase::getRequireOnlyOneParameterErrorMessages() was removed (deprecated since 1.24).
* ApiBase::getResultProperties() was removed (deprecated since 1.24).
* ApiBase::getTitleOrPageIdErrorMessage() was removed (deprecated since 1.24).
* ApiBase::parseErrors() was removed (deprecated since 1.24).
* Remove related constants ApiBase::PROP_ROOT, ApiBase::PROP_LIST,
ApiBase::PROP_TYPE, ApiBase::PROP_NULLABLE.
Patches were submitted for remaining uses in Gerrit extensions.
Change-Id: Idea70300874258fbcb9deef6504eb55f2ebe8d6c
