NineChime forum

Do you know if file uploads work, using the "Upload" option instead of "Draw"?

Many times this is caused by an aggressive server security policy, which causes the picture data to be simply "thrown out" without returning an error.  Normally, if the oekaki can't receive or save picture data, it will return a specific error to the applet, and something will show up in the Wacintaki log file.  You may want to check your server's error log to see if any security warnings are being issued.  More and more servers these days, especially those running on free hosts, will reject uploaded data without returning an error (such as HTTP 403 or HTTP 500).  Since ChibiPaint is returning HTTP 200, I assume the server is just rejecting uploads.

The reason for rejecting uploads is that some servers will only accept file uploads that come from common, well-know applications.  Firefox, IE, Opera, and Chrome may not have a problem uploading files, but Java will.  If you can upload files with a web browser, but cannot submit pictures, that may be the case, here.  The only way to fix this is to ask your sysadmin for help and tell them that Java needs to be recognized as a valid client for sending chunked data over HTTP.  Many web hosts do this to prevent their bandwidth from being consumed by bots or zombie PCs infected with viruses.

The code that handles uploads is limited to only two files:

- "paintsave.php", which handles thumbnails and the actual saving of the image data.
- "shiget.php", or the respective collection code for each applet your board supports.  This collects the raw data over HTTP and parses it into the picture and header information.

My guess is that "shiget.php", "chibipaintget.php", or "paintbbsget.php" is the problem, and is probably related to authorization.  Forums generally use a different and stronger password encryption system than Wacintaki, and there might be character conflicts, truncation, or HTML encoding issues.

This can be very complicated to diagnose, so it'd be easier if I registered and took a look at what is being put into the applet headers.  If something isn't being encoded properly, that can be detected right away.

I was using SMF's $context['is']['logged'] to check and see if a user was logged into SMF. (If they aren't they can't even get to the Oekaki Board.) Then I was passing $context['user']['name'] to $OekakiU. This may of course be where my problem is because I didn't pass anything through for $OekakiPass and essentially stripped password functions out of a lot of files since the sessions were being handled by SMF.

I'll have to go back and play with it some more now that I know better where this is falling through.

Last edited by MattH41 (06-03-2009 11:02:05)

Well, ChibiPaint works just fine for me.  It's hard to tell what the exact server response is, because Java gets it, and the web browser does not.  So, you can't use a tool like Live HTTP Headers to find out what the server is saying.

The basic procedure is this:

- The server gets the picture data, parses it, and saves it as a WIP.

- The server sends a plain text message to the applet with the function "print_ok()".  This tells the applet that the picture was received properly.

- The applet forwards the web browser to the comment page, so the artist can leave a comment, set a password, etc.

- Once a main comment is assigned to the picture, it is changed from a WIP to a regular post.

So, if the web browser does not forward to the comment page, and no comment is left, then the picture will remain a WIP.  We need to find out why the server is either sending a garbled response, or why the applet is misinterpreting it.

My guess is this:  PHP might be printing something before the "print_ok()" function is called and the HTTP header is set to text/plain.  PHP error messages can do this.  The applet will not print the exact output from the server, so PHP errors won't show up.  Your server has an "error_log" file in the oekaki folder, which means PHP is set up to dump errors into this file.  Take a look at it.  You will have to download it to your computer via FTP to read it, as by default, it is not a public file (I can tell it's there, but I can't view the contents).

It's also possible that the problem is with your own computer.  Checking for an update to Java can help, or try temporarily disabling any non-Microsoft firewall software you're using.

I hope this helps!

I got it integrated and running. You can see it live at http://www.furcartzone.com.

Thank you for your help. Do you have a paypal I can send a donation to?