1

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
----------------------------------------------------------
1

This is one of those extremely frustrating errors that can be caused by a lot of things.

Here is a 300+ post long issue in the Drupal 6 Filefield issue queue: HTTP error 0 #297035

Basically, HTTP Error 0 means that an error occurred during some JavaScript or AJAX/AHAH behavior... and that's as helpful is it gets. The linked issue suggests hundreds of potential causes, but I don't think the short summary's list of solutions necessarily applies to your specific case. I'm also not 100% certain that the upload/js 403 issue is related.

You indicated that it only happens when a content field is set to allow HTML. That makes me hopeful that if you enable error logging something is going to show up somewhere. Even if you don't see anything in your Drupal logs it might be worth digging around for where your PHP is configured to put logs.

You might also want to skim the whole thread and see if one of the many many many solutions there will have a surprise solution.

  • I already figured out it only happens, when there are html tags in content (it doesn't matter if it's allowed - even in plain text if u put <p></p> tags it happens). And it happens always like that and only then, maybe thats a bit more helpful info – Kelu Thatsall Nov 28 '13 at 8:13
  • Without error logs to work with it's just guesswork. Maybe you have an installation of PHP whose htmlspecialchars() function crashes Apache. – Weston Wedding Dec 1 '13 at 20:37
  • htmlspecialchars works, but how do I get specific error logs? – Kelu Thatsall Dec 1 '13 at 21:02
  • If error logging is enabled in Drupal, it catches almost all the errors and warnings that happen and can be viewed at admin/reports/dblog. Sometimes failures don't make in onto there, though, so you need to go to the source. grep error_log /etc/php.ini to find out where PHP's logging is happening. Then make the error happen and look in that log and cross your fingers. You might also want to find your apache error log, but the config file you need to find is dependent on your operating system. cyberciti.biz/faq/apache-logs – Weston Wedding Dec 3 '13 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.