Произошла http ошибка 0 n filefield

After just spending most of the day on this and this being one of the most frustrating issues i’ve come across with Drupal I thought i’d write a list of fixes for this Filefield AHAH ‘HTTP error 0 occured’ as it may help someone else. There are lots of suggestions on Drupal.org but it takes a lot of searching to go through them all.

My setup is running Drupal 6.22 with the Seven admin theme, PHP 5.3.5, Apache running on CentOS. The image and file modules i’m using are: ImageAPI 6.x-1.10, Filefield 6.x-3.10,ImageField 6.x-3.10, Filefield Paths 6.x-1.4.

Check Your Theme Scripts

I’m putting this one first as it was the cause of the problem for me. I thought what had recently changed — I had just moved servers but had also enabled a javascript preloader on the website. The javascript for the upload field (if you view source on the page) is within the variable in your admin themes page.tpl.php. The and the variable were both contained within the head part of the document. I moved them both to before the closing body tag and then the script processed correctly and the images uploaded without the error.

<?php print $scripts; ?>
<?php print $closure; ?>
</body>

EDIT: This wasnt actually the problem in the end. It was the javascript preloader interfering with the Drupal AHAH script! Caching issues made it difficult to test for, oh well got there in the end 🙂

Disable Javascript In Your Browser and Plugins 

Disabling javascript is an obvious quick fix to the problem as it then stops the javascript from even running on the page so the error is not displayed. The next step would be to disable all plugins in your browser, if that fixes the problem, enable each plugin one by one and test to see which is causing the issue. This was a problem for some people using different browsers on different OS’s.

Update Your File and Image Modules

Some older versions of the filefield module had the AHAH section commented out, not sure why, but updating your modules to the most recent versions would be the first thing to check.

ImageAPI — http://drupal.org/project/imageapi
Filefield — http://drupal.org/project/filefield
Filefield Paths (probably not the problem but a handy module to have) — http://drupal.org/project/filefield_paths
Imagefield — http://drupal.org/project/imagefield

Also check that the permissions are correct on the folders and files in your sites/default/files directory.

Upgrade Jquery

Install the jquery update module to update to a newer version of Jquery — http://drupal.org/project/jquery_update. If that doesnt fix the problem then its probably best to disable this as it could cause issues elsewhere.

Check Your Upload Limits

This wasnt the cause of the problem for me but you should set this up even if you’re not having problems. Setting post and upload sizes will limit the size of the file that can be uploaded which you will see when creating the image or file field in CCK. If your limit is too small, increase the post_max_size and upload_max_filesize to what you need. Increasing the memory_limit will allow for larger image processing and setting a longer max_execution_time gives scripts longer process and can fix a lot of WSOD errors.

In your php.ini add or modify:

post_max_size 2M
upload_max_filesize 2M
memory_limit 96M
max_execution_time 120

OR if you dont have access to php.ini, In your .htaccess add:

<IfModule mod_php5.c>
php_value post_max_size 2M
php_value upload_max_filesize 2M
php_value memory_limit 96M
php_value max_execution_time 120
</IfModule>

Check FastCGI config

There’s a MaxRequestLen value that can be set if you are using PHP as FastCGI in:

/etc/httpd/conf.d/fcgid.conf

You may see this has been set to 128KB, change this to something a lot higher like 15mb:

MaxRequestLen 15728640

Install ImageMagick

SSH into your server and enter the following commands to install ImageMagick to process the images instead of PHP’s built in GD2. ImageMagick-6.7.2-9 is the most recent version when writing this, you may want to visit ftp://ftp.imagemagick.org/pub/ImageMagick and check for the newest version. I’ll keep this as ImageMagick-6.7.2-9 as I this is what i’ve installed and know it works.

wget ftp://ftp.imagemagick.org/pub/ImageMagick/ImageMagick-6.7.2-9.tar.gz

tar xvfz ImageMagick-6.7.2-9.tar.gz

cd ImageMagick-6.7.2-9

./configure

make

sudo make install

sudo ldconfig /usr/local/lib

make check

Then you want to go to into Drupal admin /admin/settings/imageapi and set the image toolkit as Image Magick. I also had to go to configure and set the path to the convert binary as:

/usr/local/bin/convert

I then had open_basedir errors and so had to allow PHP to access the /usr/local/bin/convert directory. Locate your websites conf folder in the virtual host folder:

var/www/vhosts/yourdomain.com/conf

Then create a file in that folder called:

vhost.conf

Add to the file:

<Directory /var/www/vhosts/yourdomain.com/httpdocs>
php_admin_value open_basedir /var/www/vhosts/yourdomain.com/httpdocs/:/tmp/:/usr/local/bin/convert
php_admin_value include_path /var/www/vhosts/yourdomain.com/httpdocs/:/tmp/:/usr/local/bin/convert
</Directory>

Then you need to restart apache:

/etc/init.d/httpd

If you have any other solutions to this issue which doesnt fall under any of the above please post details in the comments.

Tag1 supports the Drupal Project.

TLDR: I already figured out when exactly my problem happens so for people too lazy to read full thread please read here. Whenever I have some html content in any textfield in Open Atrium (I’m not sure if that happens just in OA or in Drupal) and I want to upload a file an error «An HTTP Error occured 0» pops up. When I’m disabling javascript I get Error: 403 Forbidden. The HTML must be there before I want to upload something, so it happens when I’m editing some field, not just creating it (so it must be in the database already). And one more thing — it happens also on newly installed instance of Open Atrium downloaded from Drupal’s site. (version 1.7)

I’m using open-atrium in drupal. Recently an error started to pop up — «An HTTP Error occured 0» while I try to upload files while editing a node (not while I’m commenting — there it works).

EDIT: I figured when it happens and why, but I cannot figure how to repair it! This issue happens when I have HTML inside content editor. When I select plain text or Markdown the issue doesn’t show up and I can upload files! What do you suggest I can try now?

I checked, the file is actually uploaded to server (so it’s not permission to directory problem) and I have jQuery Update installed (as some other topics state).

I disabled JavaScript (so it wouldn’t be sent with ajax) and the problem still persisted — this time with 403 Permission Error. My page is like this: http://example.com/example/node/225/edit and the permission error is showing something like this:

POST http://example.com/example/upload/js 403 (Forbidden)

Does anyone have any idea what might be wrong? How can I debug it to check what’s happening before/after upload? Remember that I actually upload the file to the server, but it just won’t attach to the topic while editing (it works on comments).

I’m attaching full HTTP headers sent with the request when JS was disabled:

http://example.com/example/node/225/edit

POST /example/node/225/edit HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://example.com/example/node/225/edit
Cookie: __utma=118809371.977078118.1375778041.1376992641.1378820396.3; __utmz=118809371.1375778041.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SESSc3f285b6f1567ee5f358af2cabd3c968=5ae3330852770b675d5a76c42a9bbcf1; Drupal_l10n_client=0; DrupalAdminToolbar=expanded%3D0; has_js=1
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------198552096025328
Content-Length: 277355
-----------------------------198552096025328
Content-Disposition: form-data; name="title"

testtest
-----------------------------198552096025328
Content-Disposition: form-data; name="casetracker[pid]"

128
-----------------------------198552096025328
Content-Disposition: form-data; name="casetracker[assign_to]"

Test Test
-----------------------------198552096025328
Content-Disposition: form-data; name="casetracker[case_status_id]"

4
-----------------------------198552096025328
Content-Disposition: form-data; name="casetracker[case_priority_id]"

2
-----------------------------198552096025328
Content-Disposition: form-data; name="casetracker[case_type_id]"

11
-----------------------------198552096025328
Content-Disposition: form-data; name="field_due_date[0][value][date]"

11/23/2013
-----------------------------198552096025328
Content-Disposition: form-data; name="teaser_include"

1
-----------------------------198552096025328
Content-Disposition: form-data; name="body"

<p>fadsfdsf&nbsp;<strong>gfgdf</strong> fgd s</p>
-----------------------------198552096025328
Content-Disposition: form-data; name="format"

4
-----------------------------198552096025328
Content-Disposition: form-data; name="notifications_team[selected]"

1,11
-----------------------------198552096025328
Content-Disposition: form-data; name="files[upload]"; filename="tinymce_4.0.6.zip"
Content-Type: application/octet-stream

PK
HTTP/1.1 403 Forbidden
Content-Encoding: gzip
Vary: Accept-Encoding
X-Powered-By: PHP/5.2.9
Content-Type: text/html
Transfer-Encoding: chunked
Date: Tue, 19 Nov 2013 11:57:47 GMT
Server: LiteSpeed
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
----------------------------------------------------------

TLDR: I already figured out when exactly my problem happens so for people too lazy to read full thread please read here. Whenever I have some html content in any textfield in Open Atrium (I’m not sure if that happens just in OA or in Drupal) and I want to upload a file an error «An HTTP Error occured 0» pops up. When I’m disabling javascript I get Error: 403 Forbidden. The HTML must be there before I want to upload something, so it happens when I’m editing some field, not just creating it (so it must be in the database already). And one more thing — it happens also on newly installed instance of Open Atrium downloaded from Drupal’s site. (version 1.7)

I’m using open-atrium in drupal. Recently an error started to pop up — «An HTTP Error occured 0» while I try to upload files while editing a node (not while I’m commenting — there it works).

EDIT: I figured when it happens and why, but I cannot figure how to repair it! This issue happens when I have HTML inside content editor. When I select plain text or Markdown the issue doesn’t show up and I can upload files! What do you suggest I can try now?

I checked, the file is actually uploaded to server (so it’s not permission to directory problem) and I have jQuery Update installed (as some other topics state).

I disabled JavaScript (so it wouldn’t be sent with ajax) and the problem still persisted — this time with 403 Permission Error. My page is like this: http://example.com/example/node/225/edit and the permission error is showing something like this:

POST http://example.com/example/upload/js 403 (Forbidden)

Does anyone have any idea what might be wrong? How can I debug it to check what’s happening before/after upload? Remember that I actually upload the file to the server, but it just won’t attach to the topic while editing (it works on comments).

I’m attaching full HTTP headers sent with the request when JS was disabled:

http://example.com/example/node/225/edit

POST /example/node/225/edit HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://example.com/example/node/225/edit
Cookie: __utma=118809371.977078118.1375778041.1376992641.1378820396.3; __utmz=118809371.1375778041.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SESSc3f285b6f1567ee5f358af2cabd3c968=5ae3330852770b675d5a76c42a9bbcf1; Drupal_l10n_client=0; DrupalAdminToolbar=expanded%3D0; has_js=1
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------198552096025328
Content-Length: 277355
-----------------------------198552096025328
Content-Disposition: form-data; name="title"

testtest
-----------------------------198552096025328
Content-Disposition: form-data; name="casetracker[pid]"

128
-----------------------------198552096025328
Content-Disposition: form-data; name="casetracker[assign_to]"

Test Test
-----------------------------198552096025328
Content-Disposition: form-data; name="casetracker[case_status_id]"

4
-----------------------------198552096025328
Content-Disposition: form-data; name="casetracker[case_priority_id]"

2
-----------------------------198552096025328
Content-Disposition: form-data; name="casetracker[case_type_id]"

11
-----------------------------198552096025328
Content-Disposition: form-data; name="field_due_date[0][value][date]"

11/23/2013
-----------------------------198552096025328
Content-Disposition: form-data; name="teaser_include"

1
-----------------------------198552096025328
Content-Disposition: form-data; name="body"

<p>fadsfdsf&nbsp;<strong>gfgdf</strong> fgd s</p>
-----------------------------198552096025328
Content-Disposition: form-data; name="format"

4
-----------------------------198552096025328
Content-Disposition: form-data; name="notifications_team[selected]"

1,11
-----------------------------198552096025328
Content-Disposition: form-data; name="files[upload]"; filename="tinymce_4.0.6.zip"
Content-Type: application/octet-stream

PK
HTTP/1.1 403 Forbidden
Content-Encoding: gzip
Vary: Accept-Encoding
X-Powered-By: PHP/5.2.9
Content-Type: text/html
Transfer-Encoding: chunked
Date: Tue, 19 Nov 2013 11:57:47 GMT
Server: LiteSpeed
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
----------------------------------------------------------

Отправить комментарий