Hi,
I want to use the new Upload-API. I have seen that I cannot upload per URL to Commons because I (my bot) haven't the upload_by_url right. So I change my tool to the file argument:
$new_file = <Name of the target file>; $url = <URL of the source file>; $desc = <Description>; $filename = <Name of the source file>; $this->server = 'commons.wikimedia.org';
$connect = fsockopen ($this->server, 80, $err_num, $err_str, 10); $token = $this->get_token(); $file = file_get_contents( $url ); $query = "POST /w/api.php?format=php&action=upload&filename=".urlencode($new_file)."&token= ".urlencode($token)."&file=".urlencode($filename)."&comment=".urlencode($des c)." HTTP/1.1 Host: ".$this->server." Cookie: ".$cookies." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20041107 Firefox/1.0 Content-Type: multipart/form-data Content-Length: ".strlen($file)." Content-Disposition: form-data; name="".$filename.""; filename="".$filename.""
".$file." \r\n\r\n"; fputs ($connect,$query);
But now I get this error: array(1) { ["error"]=> array(2) { ["code"]=> string(12) "missingparam" ["info"]=> string(69) "One of the parameters sessionkey, file, url, enablechunks is required" } }
What is wrong?
Viele Grüße Jan
On Wed, Oct 21, 2009 at 12:15 PM, Jan Luca jan@jans-seite.de wrote: [...]
Content-Type: multipart/form-data Content-Length: ".strlen($file)." Content-Disposition: form-data; name="".$filename.""; filename="".$filename.""
".$file." \r\n\r\n";
You do set your content-type to multipart/form-data, but your content is not actually multipart/form-data encoded. A multipart/form-data encoded request looks something like this:
POST / HTTP/1.1 Content-Type: multipart/form-data; boundary=abc Content-Length: 1234
--abc Content-Disposition: form-data; name="%s"; filename="%s" Content-Type: application/octet-stream
<FILECONTENT> --abc Content-Disposition: form-data; name="%s"
data --abc Content-Disposition: form-data; name="%s"
data --abc--
Bryan
Hi,
is "Content-Length:" the other header, too`
Other header e.g:
--abc Content-Disposition: form-data; name="%s"; filename="%s" Content-Type: application/octet-stream
Viele Grüße Jan
-----Ursprüngliche Nachricht----- Von: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Bryan Tong Minh Gesendet: Mittwoch, 21. Oktober 2009 12:25 An: Wikimedia developers Betreff: Re: [Wikitech-l] Problem with Upload API
On Wed, Oct 21, 2009 at 12:15 PM, Jan Luca jan@jans-seite.de wrote: [...]
Content-Type: multipart/form-data Content-Length: ".strlen($file)." Content-Disposition: form-data; name="".$filename.""; filename="".$filename.""
".$file." \r\n\r\n";
You do set your content-type to multipart/form-data, but your content is not actually multipart/form-data encoded. A multipart/form-data encoded request looks something like this:
POST / HTTP/1.1 Content-Type: multipart/form-data; boundary=abc
--abc Content-Disposition: form-data; name="%s"; filename="%s" Content-Type: application/octet-stream
<FILECONTENT> --abc Content-Disposition: form-data; name="%s"
data --abc Content-Disposition: form-data; name="%s"
data --abc--
Bryan
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi,
On Wed, Oct 21, 2009 at 12:37 PM, Jan Luca jan@jans-seite.de wrote:
is "Content-Length:" the other header, too`
It is in my experience and as far as I am aware not necessary. Please see RFC2388 [1] for more information. What usually also helps is sniffing your browser traffic (Firebug under firefox).
Bryan
"Bryan Tong Minh" bryan.tongminh@gmail.com wrote in message news:fd5886130910210324l409d2cc6m31831366ae4bb737@mail.gmail.com...
On Wed, Oct 21, 2009 at 12:15 PM, Jan Luca jan@jans-seite.de wrote: [...]
Content-Type: multipart/form-data Content-Length: ".strlen($file)." Content-Disposition: form-data; name="".$filename.""; filename="".$filename.""
".$file." \r\n\r\n";
You do set your content-type to multipart/form-data, but your content is not actually multipart/form-data encoded. A multipart/form-data encoded request looks something like this:
POST / HTTP/1.1 Content-Type: multipart/form-data; boundary=abc Content-Length: 1234
--abc Content-Disposition: form-data; name="%s"; filename="%s" Content-Type: application/octet-stream
<FILECONTENT> --abc
What is the second "%s" in the above line? Is this instead of having a separate form-data element with name="filename", or is it a duplicate of that element, or is it something entirely different?
I note that RFC 2388 says: "The original local file name may be supplied as well, either as a "filename" parameter either of the "content-disposition: form-data" header or, in the case of multiple files, in a "content-disposition: file" header of the subpart. The sending application MAY supply a file name; if the file name of the sender's operating system is not in US-ASCII, the file name might be approximated, or encoded using the method of RFC 2231."
If RFC 2388 says that the sending application MAY supply a file name, why is the API treating this as a REQUIRED parameter?
Russ
On Wed, Oct 21, 2009 at 4:29 PM, Russell Blau russblau@hotmail.com wrote:
--abc Content-Disposition: form-data; name="%s"; filename="%s" Content-Type: application/octet-stream
What is the second "%s" in the above line? Is this instead of having a separate form-data element with name="filename", or is it a duplicate of that element, or is it something entirely different?
name is the name of the form element (wpUploadFile) and filename the name of the file (picture.jpg)
If RFC 2388 says that the sending application MAY supply a file name, why is the API treating this as a REQUIRED parameter?
It is not, as far as I can see. It is requiring the form element "filename" and ignoring the filename attribute from the file all together.
Bryan
On Wed, Oct 21, 2009 at 4:55 PM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
name is the name of the form element (wpUploadFile) and filename the name of the file (picture.jpg)
(In case of the api wpUploadFile is simply "file"; wpUploadFile is for the regular upload form)
[adding mediawiki-api since this seems to be more relevant to that list]
"Bryan Tong Minh" bryan.tongminh@gmail.com wrote:
On Wed, Oct 21, 2009 at 4:29 PM, Russell Blau russblau@hotmail.com wrote:
--abc Content-Disposition: form-data; name="%s"; filename="%s" Content-Type: application/octet-stream
What is the second "%s" in the above line? Is this instead of having a separate form-data element with name="filename", or is it a duplicate of that element, or is it something entirely different?
name is the name of the form element (wpUploadFile) and filename the name of the file (picture.jpg)
If RFC 2388 says that the sending application MAY supply a file name, why is the API treating this as a REQUIRED parameter?
It is not, as far as I can see. It is requiring the form element "filename" and ignoring the filename attribute from the file all together.
So, basically, the API for action=upload is (a) not compliant with RFC 2388, and (b) failing with a misleading error message when the client fails to supply a parameter that isn't used at all?
Russ
2009/10/21 Russell Blau russblau@hotmail.com:
So, basically, the API for action=upload is (a) not compliant with RFC 2388, and (b) failing with a misleading error message when the client fails to supply a parameter that isn't used at all?
Neither of these is true. The filename parameter specifies the name of the file ON THE WIKI, like the second textbox in Special:Upload does.
Roan Kattouw (Catrope)
Hi! I've made significant cleanup and restructurization of my extension's code that I'd like to submit to SVN. Before trying to submit my extension, I'd like to ask two important questions related to Parser and Article cache.
1. I've implemented my own parser function. The description of function is located at the following page: http://www.mediawiki.org/wiki/Extension:QPoll#qpuserchoice_parser_function
The source code class qp_FunctionsHook is located in 'qp_user.php' file inside tgz archive: http://mediawiki.narod.ru/QPoll_0.6.0.tgz (if the one cares to take a quick look)
The function seems to work: it returns a string when #qpuserchoice function parameters are correct, or returns an array( 0=>'<span class="error">qpuserchoice: ' . wfMsgHTML( 'qp_func_' . $this->error_message, htmlspecialchars( $this->pollAddr ), htmlspecialchars( $this->question_id ), htmlspecialchars( $this->proposal_id ) ) . '</span>', 'isHTML'=>true ); in case of error.
I've recieved a bug report from extension user who complained that #iferror check on my function fails. Quick test shows that is true: * {{#expr: 1 + 1 }} *** displays correct result * {{#iferror: {{#expr: 1 + 1 }} | error | correct }} *** #iferror returns correct * {{#expr: 1 + X }} *** displays error message * {{#iferror: {{#expr: 1 + X }} | error | correct }} *** #iferror returns error * {{#qpuserchoice: #almaz1}} *** displays error message (not enough function parameters given) * {{#iferror: {{#qpuserchoice: #almaz1}} | error | correct }} *** #iferror returns correct - though there should be an error !!! * {{#qpuserchoice: #almaz1|3|2}} *** displays correct result (when the poll was previousely defined and submitted) * {{#iferror: {{#qpuserchoice: #almaz1|3|2}} | error | correct }} *** #iferror returns correct
(I know that ParserFunctions returns '<strong class="error">', instead of span - I've tried that with no change)
When checking for #iferror implementation (in 'extensions/ParserFunctions/ParserFunctions.php'), the method iferror( &$parser, $test = '', $then = '', $else = false ) recieves correct $test parameter values from "erroneous" #expr function: string (105) "<strong class="error">Ошибка выражения: неопознанное слово «x»</strong>" ("ru" locale wiki)
but an incorrect value from "erroneous" #qpuserchoice function: string(33) "UNIQ2c0ad9e32fb631-item-1--QINU"
Positive results are correct strings for both functions, so the problem is with error generation.
2. My extension generates dynamical content. Because of that, I use $parser->disableCache() in my tag parser hook. But, the dynamical content is being changed only in two cases:
a) The user edits the page. In such case, disableCache() is not required, because Article cache should be properly flushed by core.
b) The user submits the poll. After the processing of POST data I redirect with 302. In such case, which is the best way to conditionally flush the cache - will parser->disableCache() work after the POST and before the 302? To me it looks that it won't have an effect on the next GET after the redirect. Or, I'd better use Article::doPurge() (or, that is too slow?). Dmitriy
2009/10/23 Dmitriy Sintsov questpc@rambler.ru:
- My extension generates dynamical content. Because of that, I use
$parser->disableCache() in my tag parser hook. But, the dynamical content is being changed only in two cases:
a) The user edits the page. In such case, disableCache() is not required, because Article cache should be properly flushed by core.
b) The user submits the poll. After the processing of POST data I redirect with 302. In such case, which is the best way to conditionally flush the cache - will parser->disableCache() work after the POST and before the 302? To me it looks that it won't have an effect on the next GET after the redirect. Or, I'd better use Article::doPurge() (or, that is too slow?).
I think purging after the submission of the poll would probably be good enough, so you wouldn't need disableCache().
Roan Kattouw (Catrope)
Hello,
thank you for you help! Now it works.
Viele Grüße Jan
-----Ursprüngliche Nachricht----- Von: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Bryan Tong Minh Gesendet: Mittwoch, 21. Oktober 2009 12:25 An: Wikimedia developers Betreff: Re: [Wikitech-l] Problem with Upload API
On Wed, Oct 21, 2009 at 12:15 PM, Jan Luca jan@jans-seite.de wrote: [...]
Content-Type: multipart/form-data Content-Length: ".strlen($file)." Content-Disposition: form-data; name="".$filename.""; filename="".$filename.""
".$file." \r\n\r\n";
You do set your content-type to multipart/form-data, but your content is not actually multipart/form-data encoded. A multipart/form-data encoded request looks something like this:
POST / HTTP/1.1 Content-Type: multipart/form-data; boundary=abc Content-Length: 1234
--abc Content-Disposition: form-data; name="%s"; filename="%s" Content-Type: application/octet-stream
<FILECONTENT> --abc Content-Disposition: form-data; name="%s"
data --abc Content-Disposition: form-data; name="%s"
data --abc--
Bryan
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 21/10/2009, at 11:15 AM, Jan Luca wrote:
Hi,
I want to use the new Upload-API. I have seen that I cannot upload per URL to Commons because I (my bot) haven't the upload_by_url right. So I change my tool to the file argument:
Why are you building an HTTP request by yourself? Use a library to do the HTTP request and you will save yourself a lot of problems.
-- Andrew Garrett agarrett@wikimedia.org http://werdn.us/
wikitech-l@lists.wikimedia.org