Images uploaded via jupload plugin has mime-type text/html

[Kurman]

Hi, Etienne!

Plugin works fine, but uploaded images somehow has mime-type text/html instead if jpeg, so, images cannot be viewed.

How can I fix it? Is it related with plugin or jupload itself?

here is gallery and here are uploaded images

In opera I see in image properties: Unknown
In Firefox 3: text/html
IE: Unknown

my PHP version is 5, if upload via coppermine http upload tool, images viewed fine.
Applet version - jupload V3.4.1f
Plugin version - jupload-3.2.4.zip

But, uploaded via Jupload images is not viewed, through they are not corrupted in uploaded folders, and via FTP I can get them and see. But via http they are not viewed.

[etienne_sf]

Strange enough.

  I checked the HTTP POST request. Looks nice. The mime type is image/png, image/gif or image.jpeg. Take care that a lot of parameters are sent, including the filename, which is text.

I had troubles like yours, with text encoding. That is: the file is correctly sent, but the links to the picture is wrong. So ... nothing is displayed.

Can you check upload with filename containing ASCII characters (no Russian ones) ?

Etienne

[Kurman]

Hi, Etienne!

I've checked it out, and tested again - image file names contain numeric or latin characters, also image name.

Links I cheked too, they are similar to those, which I upload by coppermine http upload tool and which are viewed without problem.

Links, file names and uploaded image file are right and good. I've cheked database too, if I upload by Jupload, it writes the correct informations in database (cp_pictures table) and in database it seems to me everething is OK.

I think Jupload doesn't make any changes in file while uploading (does it?) or corrupt it, so it didn't make mistakes while updating database table.

Actually reason should be in what cause the image file identify the mime type, and how Jupload works or makes changes in mime type..
If we could find out what makes show file as text/html instead of jpeg/image mime we would be closer to solution..

Kurman

[etienne_sf]

I really don't think there is a problem with mime/type. The PHP part doesn't take care of that. In the first versions, all uploaded files were of mime/type application.

  So the problem is not there.

I'm about to do a new release, in some days. Can you check with it, then post here to say if it's ok or no ?

Etienne

[Kurman]

Hi, Etienne!

I've just installed the new version of jupluad plugin (3.3.0.) and tried to upload image - the same sutuation as with the previous release. Image is uploaded well, but cannot be viewed.

Here is debug information:

16:43:52.232 [INFO] Debug level set to 99
16:43:52.236 [INFO] Current debug output file: C:\Users\Dell\AppData\Local\Temp\jupload_53991_log.txt
16:43:52.237 [DEBUG] setLang - language read (no country): ru
16:43:52.248 [WARN] Invalid boolean value: onError, using default value: true
16:43:52.249 [WARN] Invalid int value: true, using default value: 0
16:43:52.250 [DEBUG] Checking protocol with URL: http://www.elbrusoid.ru/cupermin/index.php?file=jupload/jupload&action=upload_picture&album=0
16:43:52.250 [DEBUG] Using non SSL socket, direct connection
16:43:52.354 [DEBUG] HEAD response: HTTP/1.1 200 OK
16:43:52.362 [DEBUG] cookie: #####; coppermine_data=#####
16:43:52.362 [DEBUG] userAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
16:43:52.363 [DEBUG] uploadPolicy parameter = CoppermineUploadPolicy
16:43:52.363 [DEBUG] uploadPolicy = wjhk.jupload2.policies.CoppermineUploadPolicy
16:43:52.363 [DEBUG] =======================================================================
16:43:52.364 [DEBUG] ======= Parameters managed by DefaultUploadPolicy
16:43:52.364 [INFO] JUpload applet, version 3.4.2rc4 [SVN-Rev: 491] (compiled: 07/25/2008 08:37 AM), available at http://jupload.sourceforge.net/
16:43:52.364 [DEBUG] Java version: 1.6.0_07
16:43:52.364 [DEBUG] Cookie: #####; coppermine_data=#####
16:43:52.366 [DEBUG] userAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
16:43:52.367 [DEBUG] List of all applet parameters:
16:43:52.368 [DEBUG]   language: ru
16:43:52.368 [DEBUG]   country:
16:43:52.368 [DEBUG] afterUploadURL: null
16:43:52.368 [DEBUG] allowHttpPersistent: false
16:43:52.368 [DEBUG] allowedFileExtensions: /jpg/jpeg/jpe/gif/png/bmp/jpc/jp2/jpx/jb2/swc/iff/asf/asx/mpg/mpeg/wmv/swf/avi/mov/psd/
16:43:52.369 [DEBUG] debugLevel: 99 (debugfile: C:\Users\Dell\AppData\Local\Temp\jupload_53991_log.txt)
16:43:52.369 [DEBUG] fileChooserIconFromFileContent: 0
16:43:52.369 [DEBUG] fileChooserIconSize: 50
16:43:52.370 [DEBUG] filenameEncoding: null
16:43:52.370 [DEBUG] lang: ru
16:43:52.370 [DEBUG] maxChunkSize: 500000
16:43:52.370 [INFO] maxFileSize: 1024000
16:43:52.370 [DEBUG] nbFilesPerRequest: 1
16:43:52.371 [DEBUG] postURL: http://www.elbrusoid.ru/cupermin/index.php?file=jupload/jupload&action=upload_picture
16:43:52.371 [DEBUG] serverProtocol: HTTP/1.1
16:43:52.371 [DEBUG] showLogWindow: true
16:43:52.371 [DEBUG] showStatusbar: true
16:43:52.372 [DEBUG] specificHeaders: null
16:43:52.372 [DEBUG] stringUploadError: ^ERROR: (.*)$
16:43:52.372 [DEBUG] stringUploadSuccess: ^SUCCESS$
16:43:52.372 [DEBUG] stringUploadWarning: ^WARNING: (.*)$
16:43:52.373 [DEBUG] urlToSendErrorTo: null
16:43:52.373 [DEBUG]
16:43:52.373 [DEBUG] ======= Parameters managed by PictureUploadPolicy
16:43:52.373 [DEBUG] fileChooserImagePreview: true
16:43:52.374 [DEBUG] highQualityPreview : false
16:43:52.374 [DEBUG] pictureCompressionQuality : 0.8
16:43:52.374 [DEBUG] pictureTransmitMetadata : false
16:43:52.374 [DEBUG] maxPicWidth : 800, maxPicHeight : 800
16:43:52.375 [DEBUG] realMaxPicWidth : 2048, realMaxPicHeight : 2048
16:43:52.375 [DEBUG] storeBufferedImage : false
16:43:52.376 [DEBUG] targetPictureFormat : null
16:43:52.376 [DEBUG]
16:43:52.376 [DEBUG] ======= Parameters managed by CoppermineUploadPolicy
16:43:52.377 [DEBUG] albumId : 1465
16:43:52.377 [DEBUG]
16:43:52.518 [DEBUG] Within componentResized
16:43:52.522 [DEBUG] PicturePanel.paint(): offscreenImage is null
16:43:52.551 [DEBUG] PicturePanel.paint(): offscreenImage is null
16:44:23.240 [DEBUG] PicturePanel.paint(): offscreenImage is null
16:44:25.875 [DEBUG] PicturePanel.paint(): offscreenImage is null

---------------------
Just now i've upgraded to v3.3.1. but alas, it doesn't take any positive effect.

Kurman

[etienne_sf]

Hi,

  If you know HTML enough, can you compare the path to the picture in the HTML page, and the real path for the relevant file on the server ?

Can you check a direct access to this path from the navigator, to check the error you get. Should be one of 'page not found', or 'access forbidden'.

Etienne

[Kurman]

hi, Etienne.

There are'nt errors in links to images. They are uploaded correctly. I also tried to move album with thiese images to another kategory, which already has images, but only images, uploaded via JUpload are not shown (if be more correctly - they are shown, but instead of image I see empty place).

Link to the image in gallery is
http://www.elbrusoid.ru/cupermin/displayimage.php?album=lastup&cat=0&pos=0

In gallery page from "view page source" I see this link to image:
albums/userpics/10002/1463/000.jpg

and by ftp I see the image in here:
(root path)/albums/userpics/10002/1463/000.jpg

If I put in navigator direct link to the image:
http://www.elbrusoid.ru/cupermin/albums/userpics/10002/1463/000.jpg
I've error 403 Forbidden

and .... )))) thank you, Ethienne! )) I've changed writerights of folder, created by JUpload and images now shown well. And we can say our problem is solved!

So, before we mark the thread as "solved", there remains one question more - how we can make Jupload plugin create folders with write permissions. (if there is'nt any configuration way to solve this, no problem, I can after creation folder by jupload and upoading all necessared images change permissions of folders myself)

And, one thing more, I remember now, Jupload while uploading can see and upload only in these folders, which are created by himself. For example jupload cannot see an album crated before from admin page of coppermine. So, maybe this problem and non-writable permissions of created by jupload folders has one solution and they are related?

Kurman

[etienne_sf]

Hi,

FYI, your http conf has a (little) security leak: I can browse your folders. My opinion is that it should be forbidden. At least, index.html should be the default page: I create one in each folder to prevent browsing through the folders.
Try: http://www.elbrusoid.ru/cupermin/albums/userpics/10002/1463/


Then, if you get the 403, the file exists, but you may not read it. So the problem should not be a write access problem, but a read one. You probably put 777 right on these directory. Correct ?   A 744, or 774 would be better.
My understanding is that you need manual right management on your server, to allow JUpload to work. Strange enough.
Are you in safe mode ? (take a look at your phpinfo, from the utility menu, when in admin mode)

About your last point: you had to change manually your folder rights, to allow JUpload to upload in existing albums. Correct ?
Hum, if yes, it looks like there is something strange here. The code that copy the file to the directory is exactly the same as the Coppermine one, except (there is always an 'except') the subfolder creation.
What was the error ?   (I thought the plugin would test it, and manage correctly this case).

Etienne

[Kurman]

Hi,

Thanks, i've put to htaccess index directory so they can't no more listed:
DirectoryIndex index.html

My php safe mode configured as "off".

In folder, created by Jupload I give 755 permissions, it work good (with 744 image is not shown), but now, as there is not problem with directory listing in folders, they can be with 777 permissions, can't they?

You are right, permissions are not given to created subfolders. But my Jupload plugin can create only subfolders, not folders.
As I've mentioned it on previous message, jupload can't view already created albums. So, for ability to upload new images I must create any album via jupload, and upload there images. If I rename this new created album, jupload can't see it too.

you had to change manually your folder rights, to allow JUpload to upload in existing albums. Correct ?

No, Jupload does'nt see existing albums at all! Jupload sees albums created by itself only. It can't see albums, created by itself, but renamed by me too. As soon as I rename album, it dissapears from Jupload. (maybe it caused by encoding, for I noticed it when I created whith name "2009" and after renamed to name in cyrillyc. Encoding is not in utf-8, my languge files are in windows-1251, so I did with your plugin language file - changed russian languge file from utf-8 to windows-1251)

My steps:
1- I create an album in jupload,
2- upload images in there,
3- go to created folder via ftp and change permissions
4- Move(not phisically) created album having new images to apropriate category in gallery.

(jupload creates albums without category - althrough jupload can see catagories in dropdown menu (while uploading) it cannot see abbums inside of catagories. When I chose a category in dropdown menu, where I want to upload images, Jupload see nothing under category. Category can't be chosed - it returns blank, just like as dropdown menu doesn't work. So I must create new album, which is not belonged to any category.

Why I change permisions: I must change permissions of subfolder, wich jupload had created to have images be shown.

And in the next step:
- Why jupload creates sub-folders and not folders?
- Why jupload don't see none of albums existing in categories?
If jupload could see existing albums, I could create necessary album by administration panel and without having to change permission rights by ftp, upload there images via Jupload.

I'll test it out with latin charachters or numeric album/category names and return. If then jupload will work good - will see all albums, and will be able to create folders, then we would say problems are caused by encoding. Maybe difference between utf-8 and windows-1251 initiates errors.

Kurman

[etienne_sf]

Hum, hum,

  my ADSL line is back, so I'm back too !!!


About your points: did you try with standard encoding? For my tests, every thing works fine. Nobody's told me he/she can't upload to albums created by JUpload or not, I can create albums in sub-categories, etc...

Then, I don't see your point about subfolders and folders: any subfolder, out of the root, is actually a subfolder of another folder ...

Etienne