On Wed, Oct 21, 2009 at 5:18 PM, Russell Blau <russblau(a)hotmail.com> wrote:
[adding mediawiki-api since this seems to be more
relevant to that list]
"Bryan Tong Minh" <bryan.tongminh(a)gmail.com> wrote:
On Wed, Oct 21, 2009 at 4:29 PM, Russell Blau
<russblau(a)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