Problem with Upload API

[Jan Luca]

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


_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Bryan Tong Minh]

On Wed, Oct 21, 2009 at 12:15 PM, Jan Luca <jan@...> 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@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Andrew Garrett-4]

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@...
http://werdn.us/


_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Jan Luca]

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@...
[mailto:wikitech-l-bounces@...] 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@...> 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@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Bryan Tong Minh]

Hi,

On Wed, Oct 21, 2009 at 12:37 PM, Jan Luca <jan@...> 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


[1] http://www.faqs.org/rfcs/rfc2388.html

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Russell Blau-2]

"Bryan Tong Minh" <bryan.tongminh@...> wrote in message
news:fd5886130910210324l409d2cc6m31831366ae4bb737@......

> On Wed, Oct 21, 2009 at 12:15 PM, Jan Luca <jan@...> 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





_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Bryan Tong Minh]

On Wed, Oct 21, 2009 at 4:29 PM, Russell Blau <russblau@...> 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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Bryan Tong Minh]

On Wed, Oct 21, 2009 at 4:55 PM, Bryan Tong Minh
<bryan.tongminh@...> 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)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Russell Blau-2]

[adding mediawiki-api since this seems to be more relevant to that list]

"Bryan Tong Minh" <bryan.tongminh@...> wrote:

>On Wed, Oct 21, 2009 at 4:29 PM, Russell Blau <russblau@...> 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




_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Jan Luca]

Hello,

thank you for you help! Now it works.

Viele Grüße
Jan

-----Ursprüngliche Nachricht-----
Von: wikitech-l-bounces@...
[mailto:wikitech-l-bounces@...] 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@...> 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@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw-2]

2009/10/21 Russell Blau <russblau@...>:
> 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)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Dmitriy Sintsov]

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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Roan Kattouw-2]

2009/10/23 Dmitriy Sintsov <questpc@...>:

> 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?).

I think purging after the submission of the poll would probably be
good enough, so you wouldn't need disableCache().

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@...
https://lists.wikimedia.org/mailman/listinfo/wikitech-l