headers
Tom | 1 Feb 2012 01:37
Picon

Re: Content-Length being written twice in HTTPHeader

This wiki is on a shared host. I don't have root access, not even a jailed shell. I don't think I can control
that with php.ini, although I do have php.ini access. 

Tom
Sent from my iPhone

On Jan 31, 2012, at 6:13 PM, OQ <overlordq <at> gmail.com> wrote:

> On Tue, Jan 31, 2012 at 5:11 PM, OQ <overlordq <at> gmail.com> wrote:
>> On Tue, Jan 31, 2012 at 4:32 PM, Platonides <platonides <at> gmail.com> wrote:
>>> On 31/01/12 17:25, Tom Hutchison wrote:
>>>> Same for all of them, whether there is 2, 3 or 4 header sets in the php
>>>> script.
>>>> 
>>>> The only time the Content-Length vanished from the header was when I
>>>> requested just the header without setting the Content-Length.
>>>> 
>>>> So the question becomes, since this server is forcing the Content-Length
>>>> to be appended to the header, how do I stop the API from writing the
>>>> extra Content-Length to the header?
>>>> 
>>>> Thanks for your help!
>>>> Tom
>>> 
>>> Looks like a nginx bug. They are always adding a Content-Length. Even if
>>> one was already provided by the cgi.
>> 
>> I'd definately check your configuration, mine send 0 content-length headers.
> 
> And by zero I meant 1.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Vogel | 1 Feb 2012 17:22

API: Fileupload with base64 encoded data

Hi!

 

Does anybody know if it is possible to upload a base64 encoded file via the API? I’ve already examined SVGEdit extension by Brion Vibber (http://www.mediawiki.org/wiki/Extension:SVGEdit) to get behind the api file upload magic. But as SVG is just text it doesn’t quite fit to my use case.

 

When I try to upload a base64 encoded file via the API (i.e. a JPEG) I just get a file with the base64 string (i.e. plaintext with base64 code) written to the MediaWiki file repo.

 

Any hints?

 

Greetings,

 

Robert Vogel

Social Web Technologien

Softwareentwicklung

Hallo Welt! - Medienwerkstatt GmbH

 

______________________________

 

Untere Bachgasse 15

93047 Regensburg

 

Tel.  +49 (0) 941 - 66 0 80 - 198

Fax   +49 (0) 941 - 66 0 80 - 189

 

www.hallowelt.biz

vogel <at> hallowelt.biz

 

 

Sitz: Regensburg

Amtsgericht: Regensburg

Handelsregister: HRB 10467

E.USt.Nr.: DE 253050833

Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani

 

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Permalink | Reply | 3 comments |
headers
Roan Kattouw | 1 Feb 2012 17:39
Picon

Re: API: Fileupload with base64 encoded data

On Wed, Feb 1, 2012 at 5:22 PM, Robert Vogel <vogel <at> hallowelt.biz> wrote:

Hi!

 

Does anybody know if it is possible to upload a base64 encoded file via the API? I’ve already examined SVGEdit extension by Brion Vibber (http://www.mediawiki.org/wiki/Extension:SVGEdit) to get behind the api file upload magic. But as SVG is just text it doesn’t quite fit to my use case.

 

When I try to upload a base64 encoded file via the API (i.e. a JPEG) I just get a file with the base64 string (i.e. plaintext with base64 code) written to the MediaWiki file repo.

 

Any hints?

Are you using a client that generates a MIME multipart POST request for you, or are you doing that yourself? If you're generating one yourself, you can simply use the Content-Transfer-Encoding: base64 header to tell the web server that the file is base64-encoded. If you're using a library or client that builds an HTTP request for you, you'll probably have to decode the base64 encoding and hand the raw file contents to the library/client.

Roan
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Permalink | Reply | 0 comments |
headers
Brad Jorsch | 1 Feb 2012 17:59

Re: API: Fileupload with base64 encoded data

On Wed, Feb 01, 2012 at 05:22:39PM +0100, Robert Vogel wrote:
> 
> Does anybody know if it is possible to upload a base64 encoded file
> via the API? I've already examined SVGEdit extension by Brion Vibber
> (http://www.mediawiki.org/wiki/Extension:SVGEdit) to get behind the
> api file upload magic. But as SVG is just text it doesn't quite fit to
> my use case.

Since HTTP POSTs may contain binary data, you can send the file without
any special encoding. That would usually be the best thing to do.

Theoretically, if you really wanted to base64-encode it you could
include a "Content-Transfer-Encoding: base64" header in the MIME part
for the file data.[1] But PHP doesn't handle this correctly,[2] so in
practice you'll probably need to use 8bit or binary encodings instead.

 [1] See RFC 2388 section 3. https://www.rfc-editor.org/rfc/rfc2388.txt
 [2] https://bugs.php.net/bug.php?id=48219
Permalink | Reply | 1 comment |
headers
Parsa | 1 Feb 2012 19:29
Picon
Favicon

Search acronym words

Dear Members,

I'm using mediawiki API to get a result with the following code:
http://en.wikipedia.org/w/api.php?action=opensearch&search=pc&limit=20&format=xml

But if you look at this link: http://en.wikipedia.org/wiki/PC
there is description like this:
   PC most commonly refers to:
    * Personal computer, a computer whose original sales price, size, and capabilities make it useful  for individuals
    * Political correctness, language or behavior that appears calculated to provide a minimum of offense

but with my API, I cannot get such a result. Please help me, how can i change my API to get a result like above.

Actually, I want to send an acronym word (e.g. PC) via API and get the suggestions. (e.g: Personal computer, Political Correctness)

Please help me to find a solution for that, I searched a lot and I could not find any solution for that. 

Yours Sincerely
Sasan Moshksar
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Permalink | Reply | 7 comments |
headers
Platonides | 1 Feb 2012 19:52
Picon

Re: Content-Length being written twice in HTTPHeader

On 01/02/12 00:13, OQ wrote:
>>> Looks like a nginx bug. They are always adding a Content-Length. Even if
>>> one was already provided by the cgi.
>>
>> I'd definately check your configuration, mine send 0 content-length headers.
> 
> And by zero I meant 1.
> 
> HTTP/1.1 200 OK
> Server: nginx/1.1.14
> Date: Tue, 31 Jan 2012 23:12:14 GMT
> Content-Type: text/html
> Content-Length: 6
> Connection: close
> X-Powered-By: PHP/5.3.9-1

Interesting.
Are you also running php as cgi?
You're running a more recent php (5.3.9-1 vs 5.2.17), so it could also
have been a fixed php bug.
Permalink | Reply | 2 comments |
headers
OQ | 1 Feb 2012 20:51
Picon

Re: Content-Length being written twice in HTTPHeader

On Wed, Feb 1, 2012 at 12:52 PM, Platonides <platonides <at> gmail.com> wrote:
> On 01/02/12 00:13, OQ wrote:
>>>> Looks like a nginx bug. They are always adding a Content-Length. Even if
>>>> one was already provided by the cgi.
>>>
>>> I'd definately check your configuration, mine send 0 content-length headers.
>>
>> And by zero I meant 1.
>>
>> HTTP/1.1 200 OK
>> Server: nginx/1.1.14
>> Date: Tue, 31 Jan 2012 23:12:14 GMT
>> Content-Type: text/html
>> Content-Length: 6
>> Connection: close
>> X-Powered-By: PHP/5.3.9-1
>
> Interesting.
> Are you also running php as cgi?
> You're running a more recent php (5.3.9-1 vs 5.2.17), so it could also
> have been a fixed php bug.

As FastCGI with php5-fpm.
Permalink | Reply | 1 comment |
headers
Tom | 1 Feb 2012 21:08
Picon

Re: Content-Length being written twice in HTTPHeader

I did solve the issue 1/2 way. 

I ended up having to replace content length with page length in that function. Commenting out the whole
function caused all kinds of issues and basically crashed the site. So apparently that function is
supplying the content length field for actual pages too.

I did open a support ticket at the host. I think I blew a gasket there because I am now on my fourth reply saying
please wait while we upgrade your question to a higher tech.

Tom
Sent from my iPhone

On Jan 31, 2012, at 5:32 PM, Platonides <platonides <at> gmail.com> wrote:

> On 31/01/12 17:25, Tom Hutchison wrote:
>> Same for all of them, whether there is 2, 3 or 4 header sets in the php
>> script.
>> 
>> The only time the Content-Length vanished from the header was when I
>> requested just the header without setting the Content-Length.
>> 
>> So the question becomes, since this server is forcing the Content-Length
>> to be appended to the header, how do I stop the API from writing the
>> extra Content-Length to the header?
>> 
>> Thanks for your help!
>> Tom
> 
> Looks like a nginx bug. They are always adding a Content-Length. Even if
> one was already provided by the cgi.
> I suspect the MediaWiki one was added in wfDoContentLength() at
> includes/OutputHandler.php Ironically, it was added in order to improve
> compatibilty with squid. You could comment that line, but the bug should
> be fixed at ngninx.
> 
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api <at> lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Permalink | Reply | 0 comments |
headers
Roan Kattouw | 1 Feb 2012 21:13
Picon

Re: Search acronym words

On Wed, Feb 1, 2012 at 7:29 PM, Parsa <parsaj00n <at> yahoo.com> wrote:
> Dear Members,
>
> I'm using mediawiki API to get a result with the following code:
> http://en.wikipedia.org/w/api.php?action=opensearch&search=pc&limit=20&format=xml
>
> But if you look at this link: http://en.wikipedia.org/wiki/PC
> there is description like this:
>    PC most commonly refers to:
>     * Personal computer, a computer whose original sales price, size, and
> capabilities make it useful  for individuals
>     * Political correctness, language or behavior that appears calculated to
> provide a minimum of offense
>
> but with my API, I cannot get such a result. Please help me, how can i
> change my API to get a result like above.
>
> Actually, I want to send an acronym word (e.g. PC) via API and get the
> suggestions. (e.g: Personal computer, Political Correctness)
>
> Please help me to find a solution for that, I searched a lot and I could not
> find any solution for that.
>
The opensearch API does title matches *only*. If you want to search in
the content of pages as well, you should use list=search.

Roan
Permalink | Reply | 1 comment |
headers
Robert Vogel | 2 Feb 2012 10:31

Re: API: Fileupload with base64 encoded data

Roan, Brad, thanks for the quick reply. 

A few words about the use case: my colleague has got a java applet that generates an image and provides this
image as base64 encoded string via a javascript interface. His javascript code grabs this string and uses
the "FormMultipart" class from Brion Vibbers SVGEdit extension
(modules/ext.svgedit.formmultipart.js) to send a request to the MediaWiki API. The
"Content-Transfer-Encoding: base64" is set. The file that is created in the MediaWiki repo is corrupted.

So long, thanks for the hints. We will keep them in mind.

---

Robert Vogel
Social Web Technologien
Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH

______________________________

Untere Bachgasse 15
93047 Regensburg

Tel.  +49 (0) 941 - 66 0 80 - 198
Fax   +49 (0) 941 - 66 0 80 - 189

www.hallowelt.biz
vogel <at> hallowelt.biz

Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani

-----Ursprüngliche Nachricht-----
Von: mediawiki-api-bounces <at> lists.wikimedia.org
[mailto:mediawiki-api-bounces <at> lists.wikimedia.org] Im Auftrag von Brad Jorsch
Gesendet: Mittwoch, 1. Februar 2012 18:00
An: MediaWiki API announcements & discussion
Betreff: Re: [Mediawiki-api] API: Fileupload with base64 encoded data

On Wed, Feb 01, 2012 at 05:22:39PM +0100, Robert Vogel wrote:
> 
> Does anybody know if it is possible to upload a base64 encoded file
> via the API? I've already examined SVGEdit extension by Brion Vibber
> (http://www.mediawiki.org/wiki/Extension:SVGEdit) to get behind the
> api file upload magic. But as SVG is just text it doesn't quite fit to
> my use case.

Since HTTP POSTs may contain binary data, you can send the file without
any special encoding. That would usually be the best thing to do.

Theoretically, if you really wanted to base64-encode it you could
include a "Content-Transfer-Encoding: base64" header in the MIME part
for the file data.[1] But PHP doesn't handle this correctly,[2] so in
practice you'll probably need to use 8bit or binary encodings instead.

 [1] See RFC 2388 section 3. https://www.rfc-editor.org/rfc/rfc2388.txt
 [2] https://bugs.php.net/bug.php?id=48219

_______________________________________________
Mediawiki-api mailing list
Mediawiki-api <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Permalink | Reply | 0 comments |

Gmane