I've tried to upgrade two Drupal system from 4.7.3 to HEAD. I got the following error:

An HTTP error 411 occured. update.php?op=do_update .

It's not depend on from which revision I start the update. mod_security is disabled.

CommentFileSizeAuthor
#14 progress-js-patch4.txt734 bytespwolanin
#11 progress-js-patch2.txt544 bytespwolanin
#6 progress.js.patch.txt525 bytesbdragon
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dries’s picture

Dries CreditAttribution: Dries commented

http://www.checkupdown.com/status/E411.html
http://nl.wikipedia.org/wiki/HTTP-statuscodes

aries’s picture

aries CreditAttribution: aries commented

Yep, it doesn't work with my Firefox 1.5.0.6, but it works with Konqueror 3.5.3 . Interesting...

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Category: bug » support
pfaocle’s picture

pfaocle
Primary language English
CreditAttribution: pfaocle commented

I get this too from 4.7.3 -> todays HEAD (updates 1000 onwards) in Firefox 2.0 Beta 2, but not in IE or Opera. Haven't looked closely at this.

bdragon’s picture

bdragon CreditAttribution: bdragon commented

Same here in Seamonkey 1.0.3/win32.

Ran the session through Fiddler, and it flagged a protocol violation. Seamonkey is neglecting to set Content-Length on the POST request. It is doing two of these invalid requests in quick succession.

POST /update.php?op=do_update HTTP/1.1
Host: here.be.dragons.rtk0.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060721 SeaMonkey/1.0.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
X-Requested-With: XMLHttpRequest
Connection: close
Cookie: PHPSESSID=1593e5b8d9a72307531dd003fff1f1e1
Pragma: no-cache
Cache-Control: no-cache

Server response (Fiddler wrapped it)

HTTP/1.1 400 Fiddler - Bad Request
Content-Type: text/html
Connection: close

HTTP/1.1 411 Length Required
Connection: close
Content-Type: text/html
Content-Length: 357
Date: Sun, 15 Oct 2006 22:50:40 GMT
Server: lighttpd/1.4.11

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>411 - Length Required</title>
 </head>
 <body>
  <h1>411 - Length Required</h1>
 </body>
</html>

For comparison, Internet Explorer adds a Content-Length: 0 and gets the proper JSON stream.

POST /update.php?op=do_update HTTP/1.1
Accept: */*
Accept-Language: en-us
Referer: http://here.be.dragons.rtk0.net/update.php?op=selection
x-requested-with: XMLHttpRequest
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Tablet PC 1.7; .NET CLR 2.0.50727)
Host: here.be.dragons.rtk0.net
Content-Length: 0
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: PHPSESSID=4e71c3572ce98a84e83921024f676fd3

and the server reply:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
X-Powered-By: PHP/4.4.4
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Sun, 15 Oct 2006 22:52:40 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Date: Sun, 15 Oct 2006 22:52:40 GMT
Server: lighttpd/1.4.11

45
{ "status": true, "percentage": 100, "message": "Updating complete" }
0

So, in summary, this appears to be a mozilla bug, or possibly a bug in the javascript.

bdragon’s picture

bdragon CreditAttribution: bdragon commented
Status: Active » Needs review
FileSize
progress.js.patch.txt525 bytes

Found it.

It's a bug in progress.js. When doing a post request, you apparently need to specify data, even if it is ''.

Don't know if this is a bug in jquery or just something overlooked... Might want to investigate further...

Dries’s picture

Dries CreditAttribution: Dries commented

If anything, this is something we want to document.

bdragon’s picture

bdragon CreditAttribution: bdragon commented
Version: x.y.z » 5.x-dev
Category: support » bug
Priority: Critical » Normal

This is still happening on my site.

Dries’s picture

Dries CreditAttribution: Dries commented
Title: An HTTP error 411 occured » An HTTP error 411 occured due to progress.js problem
Status: Needs review » Reviewed & tested by the community

I'll mark this RTBC but leave it up to Steven to commit. He has the final say on this.

ChrisKennedy’s picture

ChrisKennedy CreditAttribution: ChrisKennedy commented

I started getting this error and the patch fixed it. Without the patch I was unable to upgrade my test site - so I'd say it's pretty important to get this easy fix in.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
FileSize
progress-js-patch2.txt544 bytes

http://drupal.org/node/102567 has been marked a duplicate of this issue, though I'm getting a 406 error from Apache mod_security at the same step. According to host's tech support examination of the logs, the problem is essentially the same:

[11/Dec/2006:06:52:15 -0600] [example.net/sid#a86e874][rid#a24d934][/update.php][1] Access denied with code 406. Pattern match "^$" at HEADER("Content-Length")

The error essentially means that the POST content-length is not being specified, therefore it is being blocked.

however, the patch in #6 doesn't seem to fix this problem for me. Attached patch is a slight variation which sets the data as a non-zero length string. This does seems to fix the error, though I'll try to do more testing. I'm really a novice with JS, so maybe there is a better approach?

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Status: Reviewed & tested by the community » Needs review

needs further review and testing

Dries’s picture

Dries CreditAttribution: Dries commented

And let's document this too!

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Title: An HTTP error 411 occured due to progress.js problem » An HTTP error 406 or 411 occured due to progress.js problem
Status: Needs review » Reviewed & tested by the community
FileSize
progress-js-patch4.txt734 bytes

Ok, i revise my comment above- the patch works for me to prevent the 406 even in its form in #6. Apparently I didn't clear the browser cache at the right point. Anyhow, patch attached with two lines of code comments.

Steven’s picture

Steven CreditAttribution: Steven commented
Status: Reviewed & tested by the community » Fixed

Committed to HEAD, thanks.

Anonymous’s picture

(not verified) CreditAttribution: commented
Status: Fixed » Closed (fixed)
swmerrill’s picture

swmerrill CreditAttribution: swmerrill commented
Title: An HTTP error 406 or 411 occured due to progress.js problem » An HTTP error 406 occured. update.php?op=do_update
Version: 5.x-dev » 5.0
Status: Closed (fixed) » Active

I'm running Firefox 2.0.0.1 and Postgresql 8.1.6. When I try to run update.php, I get the http 406 error noted in the title. This is similar to an earlier bug in progress.js but I checked and the patch for that bug is definitely in progress.js.

Apache gives me the following error:

[Thu Jan 18 15:15:13 2007] [error] [client 209.218.83.146] mod_security: Access denied with code 406. Pattern match "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)" at HEADER("Content-Type") [severity "EMERGENCY"] [hostname "www.deargrandkids.com"] [uri "/update.php?op=do_update"]
~
I haven't been able to find a work-around.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

Is your host running mod_security? If so, there may be no easy solution, depending on their settings.

When I was seeing this problem, tried it on two severs on the same host- one gave a 406, one not. turned out that that been incorrectly configured to have slightly different mod_security settings.

Does it work if you disable JS temporarily?

swmerrill’s picture

swmerrill CreditAttribution: swmerrill commented

Yes, disabling Javascript in the Firefox browser fixed the problem.

swmerrill’s picture

swmerrill CreditAttribution: swmerrill commented

Yes, disabling Javascript in the Firefox browser fixed the problem. Many thanks!

bdragon’s picture

bdragon CreditAttribution: bdragon commented
Status: Active » Closed (fixed)