Posted by dicreat on January 14, 2010 at 6:42am
4 followers
Jump to:
| Project: | jUpload for Imagefield |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I'm using Drupal 6.15 under Nginx/0.7.62 with php-cgi. Imagefield and imagecache are working correctly without jifupload.
After installed jifupload I have error when I try to add new or edit existing node:
"Unable to access to the postURL: 'http://some_my_site.com/jifupload/gallery/field_image/0"
In my proxy-server's log:
Browser reload detected...
Posting 727 bytes...
<autofillquery clientversion="6.1.20091119-ff"><form signature="0x3035a65dd737b4
31"><field signature="0x55545fa3"/><field signature="0x00276c14"/><field sig
nature="0x278f1086"/><field signature="0xf6d9c4cd"/><field signature="0x6361
85ad"/><field signature="0xe79734b2"/><field signature="0x578160f7"/><field
signature="0x9f7572ae"/><field signature="0x44c46f3f"/><field signature="0xb
34eb6fb"/><field signature="0x71eb8003"/><field signature="0x9d958a24"/><fie
ld signature="0xd7294040"/><field signature="0xba46ead8"/><field signature="
0x114db7b6"/><field signature="0x009780a7"/><field signature="0x5783e048"/><
field signature="0x7ea0e046"/><field signature="0x4ab2a2b1"/><field signatur
e="0xcebc7059"/></form></autofillquery>
+++GET 35125+++
HEAD /jifupload/gallery/field_image/0 HTTP/1.1
Host: some_my_site.com
Accept: */*
Accept-Encoding: identity
Cookie: {cut}
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6 (.NET CLR 3.5.30729)
Connection: keep-alive
+++CLOSE 35125+++After that, I see applet and it's work correctly. I was select some images and press "Upload" button. When upload finishing, I've got the error:
wjhk.jupload2.policies.PictureUploadPolicy.checkUploadSuccess(): The string "^SUCCESS$" was not found in the response body
In my proxy-server's log:
+++GET 35512+++
POST /jifupload/gallery/field_image/0 HTTP/1.1
Host: some_my_site.com
Accept: */*
Accept-Encoding: identity
Cookie: {cut}
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6 (.NET CLR 3.5.30729)
Content-Type: multipart/form-data; boundary=---------------------------q5spcxmp0es
Content-Length: 11969
Connection: keep-alive
Posting 11969 bytes...
{posting data}
+++RESP 35512+++
HTTP/1.1 200 OK
Server: nginx/0.7.62
Date: Thu, 14 Jan 2010 05:45:15 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.8
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Thu, 14 Jan 2010 05:45:13 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
+++CLOSE 35512+++Edit page don't refresh and I don't see uploaded images as on demo site http://sandbox.bigcitydev.com/jifupload, but when I press F5 in browser I see message that new node with title "Temporary title - please replace" has been created successfully. And it's true - all my images present in this node.
P.S. I have error "Unable to access to the postURL: 'http://sandbox.bigcitydev.com/jifupload/jif/field_multiple/17'" on the demo site when I try to edit test node page http://sandbox.bigcitydev.com/node/17/edit, but after all works fine.
Comments
#1
Hi, thanks for the detailed info. I have never used Nginx, so I may not be of much use on this.
Try this. You should be able to access the postURL directly in your browser.
Try to load this page:
http://some_my_site.com/jifupload/gallery/field_image/0
You should get a blank page (It's not wsod, the callback has detected that you did not upload anything, so it returns nothing).
If you can configure your server so you can access that path without an error, then it should work or we'll move on to another problem.
Let me know how it goes.
#2
Yes, I can access this page without an error.
+++GET 409+++
GET /jifupload/gallery/field_image/0 HTTP/1.1
Host: some_my_site.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 GTB6 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Cookie: {cut}
If-Modified-Since: Thu, 14 Jan 2010 17:11:32 GMT
Cache-Control: max-age=0
Connection: keep-alive
Browser reload detected...
+++RESP 409+++
HTTP/1.1 200 OK
Server: nginx/0.7.62
Date: Thu, 14 Jan 2010 17:13:02 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.8
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Thu, 14 Jan 2010 17:13:02 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Content-Encoding: gzip
+++CLOSE 409+++
#3
Early in the development of the module there was a problem with the way the applet authenticated itself. I had to use the session id in the post url. You might check how your server authenticates the connection from the applet.
#4
Today situation is a little bit different.
Applet works fine when in server log I see:
"GET /node/add/gallery HTTP/1.1" 200 24274
"GET /node/add/wjhk/jupload2/lang/lang_ru_RU.properties HTTP/1.1" 200 12120
"GET /node/add/wjhk/jupload2/lang/lang_ru_RU.properties HTTP/1.1" 200 57029
"HEAD /jifupload/gallery/field_image/0 HTTP/1.1" 200 0
I have the error above when in server log I see only one record:
"GET /node/add/gallery HTTP/1.1" 200 24276
#5
Are you changing the applet language to Russian? Did you add any parameters in the admin settings for the module?
You might try building a test page outside of drupal with just the applet. You can get it here: http://jupload.sourceforge.net/
/node/add/wjhk/jupload2/lang/lang_ru_RU.properties
This is interesting, because there shouldn't be anything at that path.
Finally, just to confirm, are you using the latest dev of the module, and 4.6 of jupload?
Thanks
#6
This problem can be fixed by upgrading to jUpload applet v. 4.5+ (4.6 recommended). The problem is probably caused by that earlier versions of jUpload were broken when HTTP request header contained empty strings. I'm not sure why they appear when jUpload is used inside of Drupal, but I've reproduced the bug (and one more bug as well) with the 4.3.2 applet version that's bundled with the module, and it was there on two Drupal installations when using three different browsers and two Java machines. Then I've upgraded to 4.6, and the problem was gone in all cases. So I'd advice you to change the applet version bundled with the module to the 4.6 version.
And thank you for the best mass upload module I've found!!! It's a pity to see it's not developed anymore :(
#7
I was not able to duplicate this in apache.
In fact the applet should not be bundled with the module.
It is still under development, but I've been busy feeding the family. Patches and co-maintainers are welcome!
#8
Well, then maybe it's caused by nginx proxiing engine, or by its combination with drupal's wrapper, I don't know... To check that should take too much resources investigating the problem, and I don't think it'd cost it when the problem looks like fixed already.
And well, maybe it'd be even better if the applet won't be there and each user should download it itself, thus making users downloading the latest edition. I think not all the users downloaded the module with the out-of-date applet bundled would be patient enough to find out the applet's download location (that isn't referenced in readme or so) and find the applet in the package downloaded...
And well, I can be co-moaintainer, since I love this module pretty much, though it'd be the first module I'll be co'maintainer of - for now I'm rather experienced in patch making only.
#9
I'm having this issue w/ nginx as well - Even upgrading to 5.0 version of the applet did not help!
#10
@obrienmd I don't have a server with nginx to test on, and don't have time to set one up. If you want to provide more details I can take a look at error messages or such, but I think nginx users are going to have to solve this and provide a patch.
Thanks.