r65049 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:r65048‎ | r65049 | r65050 >
Date:09:28, 15 April 2010
Author:btongminh
Status:resolved (Comments)
Tags:
Comment:
(bug 17941) $wgMaxUploadSize is now honored by all upload sources
Modified paths:
  • /trunk/phase3/RELEASE-NOTES (modified) (history)
  • /trunk/phase3/includes/api/ApiUpload.php (modified) (history)
  • /trunk/phase3/includes/specials/SpecialUpload.php (modified) (history)
  • /trunk/phase3/includes/upload/UploadBase.php (modified) (history)
  • /trunk/phase3/includes/upload/UploadFromUrl.php (modified) (history)

Diff [purge]

Index: trunk/phase3/includes/upload/UploadFromUrl.php
@@ -96,6 +96,13 @@
9797 fclose( $this->mCurlDestHandle );
9898 unset( $this->mCurlDestHandle );
9999
 100+ global $wgMaxUploadSize;
 101+ if ( $this->mFileSize > $wgMaxUploadSize ) {
 102+ # Just return an ok, so that the regular verifications can handle
 103+ # the file-too-large error
 104+ return Status::newGood();
 105+ }
 106+
100107 return $status;
101108 }
102109
Index: trunk/phase3/includes/upload/UploadBase.php
@@ -29,8 +29,10 @@
3030 const FILETYPE_MISSING = 8;
3131 const FILETYPE_BADTYPE = 9;
3232 const VERIFICATION_ERROR = 10;
 33+ # HOOK_ABORTED is the new name of UPLOAD_VERIFICATION_ERROR
3334 const UPLOAD_VERIFICATION_ERROR = 11;
3435 const HOOK_ABORTED = 11;
 36+ const FILE_TOO_LARGE = 12;
3537
3638 const SESSION_VERSION = 2;
3739 const SESSION_KEYNAME = 'wsUploadData';
@@ -199,6 +201,14 @@
200202 if( $this->isEmptyFile() ) {
201203 return array( 'status' => self::EMPTY_FILE );
202204 }
 205+
 206+ /**
 207+ * Honor $wgMaxUploadSize
 208+ */
 209+ global $wgMaxUploadSize;
 210+ if( $this->mFileSize > $wgMaxUploadSize ) {
 211+ return array( 'status' => self::FILE_TOO_LARGE );
 212+ }
203213
204214 /**
205215 * Look at the contents of the file; if we can recognize the
Index: trunk/phase3/includes/api/ApiUpload.php
@@ -154,6 +154,9 @@
155155 case UploadBase::EMPTY_FILE:
156156 $this->dieUsage( 'The file you submitted was empty', 'empty-file' );
157157 break;
 158+ case UploadBase::FILE_TOO_LARGE:
 159+ $this->dieUsage( 'The file you submitted was too large', 'file-too-large' );
 160+ break;
158161 case UploadBase::FILETYPE_MISSING:
159162 $this->dieUsage( 'The file is missing an extension', 'filetype-missing' );
160163 break;
Index: trunk/phase3/includes/specials/SpecialUpload.php
@@ -365,7 +365,7 @@
366366 /**
367367 * Show the upload form with error message, but do not stash the file.
368368 *
369 - * @param $message String
 369+ * @param $message HTML string
370370 */
371371 protected function showUploadError( $message ) {
372372 $message = '<h2>' . wfMsgHtml( 'uploadwarning' ) . "</h2>\n" .
@@ -522,8 +522,11 @@
523523
524524 /** Statuses that require reuploading **/
525525 case UploadBase::EMPTY_FILE:
526 - $this->showUploadForm( $this->getUploadForm( wfMsgHtml( 'emptyfile' ) ) );
 526+ $this->showUploadError( wfMsgHtml( 'emptyfile' ) );
527527 break;
 528+ case UploadBase::FILESIZE_TOO_LARGE:
 529+ $this->showUploadError( wfMsgHtml( 'largefileserver' ) );
 530+ break;
528531 case UploadBase::FILETYPE_BADTYPE:
529532 $finalExt = $details['finalExt'];
530533 $this->showUploadError(
@@ -744,6 +747,7 @@
745748 */
746749 protected function getSourceSection() {
747750 global $wgLang, $wgUser, $wgRequest;
 751+ global $wgMaxUploadSize;
748752
749753 if ( $this->mSessionKey ) {
750754 return array(
@@ -783,13 +787,16 @@
784788 'help' => wfMsgExt( 'upload-maxfilesize',
785789 array( 'parseinline', 'escapenoentities' ),
786790 $wgLang->formatSize(
787 - wfShorthandToInteger( ini_get( 'upload_max_filesize' ) )
 791+ wfShorthandToInteger( min(
 792+ wfShorthandToInteger(
 793+ ini_get( 'upload_max_filesize' )
 794+ ), $wgMaxUploadSize
 795+ ) )
788796 )
789797 ) . ' ' . wfMsgHtml( 'upload_source_file' ),
790798 'checked' => $selectedSourceType == 'file',
791799 );
792800 if ( $canUploadByUrl ) {
793 - global $wgMaxUploadSize;
794801 $descriptor['UploadFileURL'] = array(
795802 'class' => 'UploadSourceField',
796803 'section' => 'source',
Index: trunk/phase3/RELEASE-NOTES
@@ -111,6 +111,7 @@
112112 displays incorrect tabs
113113 * (bug 23190) Improved math representation for text browsers.
114114 * (bug 22015) Improved upload-by-url error handling and error display
 115+* (bug 17941) $wgMaxUploadSize is now honored by all upload sources
115116
116117 === API changes in 1.17 ===
117118 * (bug 22738) Allow filtering by action type on query=logevent

Follow-up revisions

RevisionCommit summaryAuthorDate
r65052Documentation fix for r65049.btongminh10:16, 15 April 2010
r65274Follow-up r65049: Fix constant name...raymond12:52, 19 April 2010
r76097Add UploadBase::FILE_TOO_LARGE, introduced in r65049, to shut up a fatal erro...catrope14:47, 5 November 2010

Comments

#Comment by Platonides (talk | contribs)   21:50, 15 April 2010

I don't really like that "override curl error because I know this will error later".

#Comment by Bryan (talk | contribs)   12:20, 16 April 2010

I agree that it is not optimal, however, curl will return a totally stupid error like "Failed writing body (0 != 1260)" do you have a suggestion on how to handle this properly?

#Comment by Tim Starling (talk | contribs)   05:52, 9 July 2010

In the long term we will want to split up this global variable by upload method. There's not really any reason that all upload methods should have the same maximum file size, in fact the whole reason we're developing asynchronous copy uploads is to allow for larger file sizes.

If I understand this change, the commit message does not describe it correctly. Before this change, $wgMaxUploadSize seems to be completely ignored in all cases, which is presumably a regression introduced in the HttpFunctions.php refactor. This corrects this problem, and simultaneously fixes the mostly unrelated bug 17941, which applies $wgMaxUploadSize to other methods, apart from copy uploads where it was originally introduced.

#Comment by Bryan (talk | contribs)   08:44, 9 July 2010

We indeed may want to impose a maximum per upload source, but a global one as well.

The intention of this commit was to fix bug 17941, but it indeed also fixed the regression you mention.

#Comment by Bryan (talk | contribs)   13:38, 6 January 2011

Do you want this fixed in 1.17?

#Comment by Catrope (talk | contribs)   13:39, 6 January 2011

If you mean per-source upload limits, I vote no. That'd be a new feature.

#Comment by Bryan (talk | contribs)   19:45, 6 January 2011

Fixed anyway in r79749. Up to you if you want to backport.

#Comment by Catrope (talk | contribs)   16:29, 8 January 2011

Tim, you OKed this revision in June, then un-OKed it when you made your first comment in July. You also tagged it 1.16wmf4 but never merged it. So what's up with all that, is this rev OK or not, and should it be merged to 1.16wmf4 and deployed or not?

#Comment by Tim Starling (talk | contribs)   02:19, 10 January 2011

Yes it should be deployed. I marked it "new" because I was waiting for r79749, but it can be deployed without that change. Now that we have r79749, it can be "resolved".

#Comment by Catrope (talk | contribs)   13:52, 10 January 2011

Thanks. I'll deploy this in about 5 to 6 hours unless someone beats me to it.

#Comment by Catrope (talk | contribs)   20:21, 10 January 2011

...or not. This conflicts when I try to merge it into 1.16wmf4, and I am way too tired to intelligently resolve that right now. Will try again tomorrow.

Status & tagging log