NineChime forum
Furry stuff, oekaki stuff, and other stuff.
You are not logged in.
#1 06-06-2006 20:12:20
- Ludwig
- New member
Shi-Paint Upload Problem?
I'm testing Wacintaki for a friend website and ran into a problem, i searched on the forum here about it and found nothing .. 
When uploading a drawing from shi-paint this is what i get after one screen saying the size of the picture.
I can upload images in the usual upload button .. but not with shi-paint.
http://ale-host.byethost24.com/oekaki/
I verified about ASCII in many related files and checked CHMODS's too .. anyone have a hint? thx
Update: in another browser / java it showed a more complete detail of the bug.
update2: found this comment on the manual.html -
If your server gives you a 500 error when trying to run the installer, you cannot use 777. If the server gives you a 403 error or the installer tells you the folders are still locked, you cannot use 755. In extreme cases, where both 755 and 777 do not work, try using 775.
Its about the install .. but it indicates the problem is in the CHMOD? on the shiget.php? i tryed to change it to all CHMODS possible .. no change.
Update3: Found a topic about error 500 .. saying to make sure the oekaki folder is 755 (done) and the error continues, did not found acess to the error log on my webhost.
Update4: Found another topic, about safe-mode .. checked .. my server is not in safe-mode ..
http://ale-host.byethost24.com/phpinfo.php
Generated a phpinfo file for more details.
Update5: Found on the webhost website info about what they block or not:
Important note: ByetHost servers operateunder high security levels to ensure high levels of service stabilityfor all our clients. File permissions of 666, 777 or any chmodpermission level ending in 2, 6,or 7 - for example, 777, (last 7),are not permitted as this poses every real security risk.
777is not necessary on our servers. The last bit is for the permissionsfor "everyone", but since PHP scripts run under thecustomer's user name on our server instead of the "nobody"user on most servers, " everyone" needs no permissions. Ifscripts ask for 777, 770 is sufficient and will be far moresecure.
All php and script files permissions must be set to750. All other files such as HTML, images, or anything else needingto be accessed from the web should end in a permission level endingin 4; e.g. 644.
http://byet.net/showthread.php?t=933
This restrictions can anulate the possibility to run oekaki?
Last edited by Ludwig (06-06-2006 21:26:09)
Offline
#2 06-07-2006 04:38:24
- Waccoon
- Administrator
Re: Shi-Paint Upload Problem?
Great. First 403 erorrs, and now 500. I assume PaintBBS is giving you the same problem, right?
As far as I can tell, this is not solvable. This is because PaintBBS, ShiPainter, and OekakiBBS use a rather poor method of sending information to the server, mostly to maintain compatibility with older oekaki boards. The bottom line is, if "functions.php" and "shiget.php" have the same file permissions, but you can upload picutres and NOT use ShiPainter, your server is configured to refuse data produced by ShiPainter, and all the other applets as well. I highly doubt your system administrators will allow the server to use raw POST requests, but you can try asking.
The technical slant: the applets send data to the server as a raw POST stream, which is then parsed as the variable $HTTP_RAW_POST_DATA in PHP. However, the server wants HTTP Multipart Encoded data only (which is the proper way to do it). Anything that is not properly encoded is refused by default (at least, if PHP is involved).
Offline
#3 06-07-2006 05:24:59
- Ludwig
- New member
Re: Shi-Paint Upload Problem?
Helpfull!.. so my option is Finding a new server wich is fool enough to let raw POST's on?
How about Lascaux Sketch ? (http://cellosoft.com/software/view.php?id=34 and you can draw with it on 2draw.com) I have any way to insert it in Wacintaki? and it uses other upload system?
Offline
#4 06-08-2006 04:29:26
- Waccoon
- Administrator
Re: Shi-Paint Upload Problem?
Helpfull!.. so my option is Finding a new server wich is fool enough to let raw POST's on?
I have a feeling that's the only option. I'd like to know HOW this is disabled in the first place to see if there's a workaround available. I don't see anything in my Apache web server config file, though, so it may be an OS-dependant issue. I use Windows, so lots of features (and flukes) available to UNIX users don't work on my own test server. I've also found that "NineChime" is a really flexible server, so my own "real-world" server doesn't give me a lot of the problems many people face on free servers.
I guess I should spend more time hanging out on UNIX administration forums. 
Several people have had this problem, though, so if I find anything out, I will make an announcement.
How about Lascaux Sketch?
I've been waiting for the official release for a long time, but so far it has been in "beta" forever and is exclusive to 2draw.net.
Offline
#5 06-08-2006 05:00:45
- Ludwig
- New member
Re: Shi-Paint Upload Problem?
Would be nice if someone pointed out some freehosts that actualy worked for them .. =P
My friend got one of those http://www.oekakiart.com partnership oekakis for him! so no problem.
I was reading the shi-painter translated manual and seen some stuff about the "Poo" upload system and the new system .. they "upgraded" from the "Poo" and did another crap? XD
(sorry the "slang" could not hold myself!)
Cos the problem you discribed is the same problem he said about the "poo" system .. but on the new system there is "$HTTP_RAW_POST_DATA" too!
XD
Offline
#6 06-09-2006 05:49:53
- Waccoon
- Administrator
Re: Shi-Paint Upload Problem?
Yes. The "Poo" system (referring to the Japanese nickname of the programmer) involves sending a content length header and picture data only. It's less sophsticated than the method used by ShiPainter, and does not support animations, but works with the really old Perl-based OekakiBBS files. It also relies on raw POST data rather than multipart encoding.
Offline
#7 06-15-2006 21:08:40
- unix_bloke
- Guest
Re: Shi-Paint Upload Problem?
youll probably find that the unix web server is blocking the content using mod_security and enforcing the HTTP_Content-Type header to be "!(^application/x-www-form-urlencoded$|^multipart/form-data;)" 
.