Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
If a file upload is not formatted correctly for PHP to recognize it as a
file upload rather than a regular field, the API will wind up trying to
load the file contents as a text field. Since these file contents are
often a large binary file, this will tend to run out of memory trying to
apply Unicode normalization.
To prevent this and to allow for a helpful error message, mark
parameters that are supposed to be file uploads.
Bug: 44909
Change-Id: Ia4586953e2ad2d72d08852689e060e39e7920d50
The API supports chunked uploads to upload a file in multiple pieces.
But it doesn't check if the the entire file is uploaded in the first
chunk, so it winds up waiting for a subsequent chunk that can never
come.
It's actually fairly easy to fix, we just need to move the check for
"did we get the entire file?" outside of the "if we're getting a chunk
after the first" check.
Change-Id: I915c1678dfa3107f1739fed8613ab9452139b946
* (bug 44080) Also carry-over the IP and HTTP header info.
* This adds a RequestContext::importScopedSession() function.
Change-Id: Ie9c0a4d78fb719569c8149b9cc8a5430f0ac5673
Added/removed spaces after opening/before closing parentheses
Added a space after a comma
Removed unneeded parentheses in condition
Change-Id: I306091347ccaaf11dee0cdfda3019cb0c12be51b
For historical reasons, all our API class had a dummy __construct which
simply calls their parent constructor. This patch removes all such
occurences to save out some bytes.
Change-Id: I667955d7821f780fc5ce23823d74dedb1729b9fa
API was using SVN's version keyword which GIT does not support.
All related methods were either removed, or for those that
could have been used from extensions, emptied out.
api.php?version now shows unrecognized param warning.
Change-Id: I910ca1448ed2ed697ac19b17c486d130aa1d7e03
* Added a "stage" field to the status info. This lets clients detect
if the process failed to even start much more quickly.
* Actually unset the status from $_SESSION if set to false.
Change-Id: I29703f14625b1b10e6413db27a3964324b4679e6
* Clients can send the last chunk with 'async' to get an immediate
response and then check the status of the upload by polling the API
using the 'checkstatus' parameter.
* Pass the User object along to stash functions within UploadFromChunks.
Change-Id: Ie2ad4c7e94862a728e8a687c3195306e16a5059e
The API action=upload returns a generic error message when one or more
of the file extensions are blacklisted. It should return a more
informative message, and also return the list of blacklisted extensions
in a machine-readable format.
This changeset introduces a new message,
"api-error-filetype-banned-type", which is to
"api-error-filetype-banned" what "filetype-banned-type" is to
"filetype-banned". As a starting point, I've copied (with minor changes)
the existing filetype-banned-type message to
api-error-filetype-banned-type for all languages for which both
api-error-filetype-banned and filetype-banned-type are currently given.
This changeset also incidentally fixes an internal server error with
format=xml when the filetype-banned error is returned by the API.
Change-Id: I6b0c58fbc5b19aa55286c56fa7da2195ea683ae0
action=block/action=unblock can not have the token required because when
using the gettoken param, the token param can not set.
Change-Id: I15317f16c06f150d29c1b17de76f41a6cfa84820
The API currently doesn't return any indication of the warnings on
a successful upload where the API call had ignorewarnings=true.
This patch allows the client to handle the warnings gracefully.
Patchset 2: Document it properly.
Patchset 3 and 4: Rebase.
Patchset 5: Document it even more properly.
Patchset 6: I didn't understand doxygen properly.
Change-Id: I09c8f3dc13832df55a0ffa9e8b9380aaa4038cf1
Added information about the properties of the results of API calls
to action=paraminfo, including information about "property groups":
what should the prop parameter be set to to get that property.
Uses the same format for types as parameters already do.
The output format of some modules doesn't fit this, so the result
properties for them weren't added, or only partially.
Partially implemented modules:
* expandtemplates:
parsetree is in its own tag
* protect, allusers, backlinks, deletedrevs, info, imageinfo,
logevents, querypage, recentchanges, revisions, searchinfo,
usercontribs, userinfo, users, watchlist, upload:
response with partially complex structure
Not implemented modules:
* feedcontributions, feedwatchlist, opensearch, rds:
non-standard reponse
* help:
error is normal response; not very useful for automated tools anyway
* paraminfo, parse, pageprops, siteinfo, userrights:
response with complex structure
Change-Id: Iff2a9bef79f994e73eef3062b4dd5461bff968ab
The current API implementation has a parameter for uploads that is
called "ignorewarnings". Currently, it will not only suppress any
warnings from stopping the upload, it will also lose any data from
those warnings.
This patch is sort of on the way to solving Bug 30625, which is in
the UploadWizard extension. That extension needs to know when a file
upload *will* fail, barring a change in some data, in order to make
it easier for a user to fix the foreseeable problems. The solution is
either to fix it this way, or to somehow spoof a file upload, and see
if it succeeds. In the hopes that other extensions will also find
this useful, I opted for the former.
Change-Id: I08b4e29e89ade6cf391ae044fceb788aaba3f5b4
Chunked uploading is currently only implemented by Upload Wizard,
but is supported in MediaWiki core. It's enabled in Upload Wizard
by setting $wgUploadWizardConfig['enableChunked'] to true.
When enabled, large files will be split into smaller chunks, by
default of 1 MB. This is done through a series of API POST
requests. The file is identified by means of a 'filekey' to
allow for continuation of uploads from previous offsets.
Previously broken behavior: Files were concatenated correctly,
but instead of the whole file, one of the chunks was uploaded
to the wiki. This was due to the API using the filekey of the
chunk, as opposed to the filekey of the whole file.
In addition, this change also cleans out the stash information
for both filekeys after the upload is complete.
[Patch set 2: Whitespace fix]
[Patch set 3: Move filekey result past status check]
Change-Id: Idac94e953676787f9516051e47c006525f198fd4
It's a parctice that dates back to 2006 when the API was first written, and frankly isn't covered by the coding conventions. Same thing with the docblocks, they're all copypasted with some bits changed and don't even make sense if you look at them in the genereated code docs.
I don't feel that any of us depend on this anymore (get a better IDE), so in the inerest of consistancy it's time we said goodbye to it.
