On Wed, Oct 21, 2009 at 5:18 PM, Russell Blau russblau@hotmail.com wrote:
[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
It simply discards the filename attribute. RFC 2388 only specifies client side behaviour; it does not state whether or not the server application should do with it. My personal preference is to have filename sent along explicitly [as form field, not as parameter to the file part].
(b) failing with a misleading error message when the client fails to supply a parameter that isn't used at all?
In case the filename is not sent along as form field, it will reject the upload with the error (missingparam, filename) [which is not what the topic started got as error]. In case the filename is not sent along as file part parameter, the API does not throw an error, unless intermediate layers [such as PHP or Apache] strip the entire file in case no filename is specified. I do however not believe that this is the case, although I have not tested it myself.
The problem of the topic started was caused because he was simply sending malformed data.
Regards, Bryan
mediawiki-api@lists.wikimedia.org