392046 - can't post to a vBulletin 3.6.8 site (forum) with minefield

Status: RESOLVED INCOMPLETE

(Tech Evangelism Graveyard :: Other, defect)

Description

[patrickdrd]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081305 Firefox/2.0 MEGAUPLOAD 1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081305 Firefox/2.0 MEGAUPLOAD 1.0

I don't know when this bug started,
one thing I know though is that it started when I began using minefield,
worked fine with fx 2.0.0.6 and gran paradiso!

Someone that knows greek can follow these steps in order to reproduce it:
1. Login (or register if you don't have an account, then login) to
http://www.adslgr.com
2. Goto any thread in the forum and try to post a quick reply clicking the
submit button -> you'll get a please wait (must be div or something) message
and the page hangs in there (no post takes place).
However, if you go through the normal reply process, everything is ok.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Steve England [:stevee]]

Well first thing to do is to find a regression range using:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
- http://archive.mozilla.org/pub/firefox/nightly/

Comment 2

[Ria Klaassen (not reading all bugmail)]

I can't read Greek, but maybe [e-mail] can (sounds like a Greek name).

Comment 3

[patrickdrd]

thanx!

I wouldn't want to try all these versions steve says,
I just would like to see that fixed maybe in the next trunk or so...

Maybe mr giannopoulos could help...

Comment 4

[Bill Gianopoulos [:WG9s]]

Well,  unfortunately I am second generation American and can neither read nor write Greek.  However, I selected English on the site and had no difficulty posting to forums on this site using the 20070812 nightly build.

Comment 5

[patrickdrd]

did you use the fast reply option?
(I'm not sure if this is the name of the option in english,
but wrote sth and pressed the button below that)

Comment 6

[Bill Gianopoulos [:WG9s]]

I can confirm the issue.  It only seems to effect quick reply.  Everything else seems to work.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Any idea on regression range?  Or just steps to reproduce?

Comment 8

[patrickdrd]

thanks bill!

@boris (steps to reproduce):
1. Login (or register if you don't have an account, then login) to
http://www.adslgr.com
2. Goto any thread in the forum and try to post a quick reply clicking the
submit button -> you'll get a please wait (must be div or something) message
and the page hangs in there (no post takes place).
However, if you go through the normal reply process, everything is ok.

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

from first attempt to find a regression range i saw this regressed between
2007-05-09 (work) and 2007-05-15 (don't work)

Comment 10

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

regressed between 2007-05-13 and 2007-05-14

Work
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070513 Minefield/3.0a5pre

Don't work:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070514 Minefield/3.0a5pre

Comment 11

[Steve England [:stevee]]

Marco could you get the regression dates with the times in the build id? (On each build, do about: in the URL bar, and copy the user agent string from there)

Comment 12

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Here you are!

Work:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/2007051304 Minefield/3.0a5pre

Don't Work:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/2007051405 Minefield/3.0a5pre

Comment 13

[Steve England [:stevee]]

Thanks Marco!

Checkins to module PhoenixTinderbox between 2007-05-13 03:00 and 2007-05-14 06:00 :

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-13+03&maxdate=2007-05-14+06&cvsroot=%2Fcvsroot

Comment 14

[patrickdrd]

many thanks guys!

Comment 15

[Boris Zbarsky [:bzbarsky]]

OK, seems likely to be a regression from bug 116346.  Could someone contact the site and ask them to fix their broken code and see where that gets us?  ;)

More importantly, could someone contact the site and ask them _why_ this is breaking them?  Especially now that we've fixed the thing that broke some other software?

Comment 16

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

that is vbulletin 3.6.8 (latest version) and i think that quick reply is an internal feature (not a mod). So, if the problem is in vbulletin itself that is a big amount of forums on the net, should be tested on another vbulletin 3.6.8 forum

Comment 17

[patrickdrd]

I would agree with marco

Comment 18

[Bill Gianopoulos [:WG9s]]

I just went to the vBulletin website into there test forum which uses vBulletin 3.6.8.  There is no Quick Reply.

Comment 19

[Mike Kaply [:mkaply]]

You can login as Admin to your demo site (look in the upper right) then go to:

vBulletin Options
Message Posting and Editing Options

and turn on Quick Reply

Comment 20

[patrickdrd]

test thread:

http://www.adslgr.com/forum/showthread.php?t=122148

Comment 21

[Boris Zbarsky [:bzbarsky]]

I've sent mail to vBulletin's general contact address describing the problem; hopefully they can put me in touch with someone on their end who knows what their server code looks like so we can sort this out.  It doesn't look like they have a public way to report bugs, so this is the best I could find.  :(

Comment 22

[Mike Sullivan]

Hi,

One of the vBulletin developers here. :)

I can't actually reproduce this problem on our official forums (vBulletin.com). You need to be a registered user to use quick reply, though you can also setup an admin demo as mentioned to test it.

Tested build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081505 Minefield/3.0a8pre

Quick reply doesn't actually submit a form (directly) by default -- it uses AJAX. We set our own header there as is:

this.handler.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');

It actually seems to be AJAX related. An easy test is to try to get a new CAPTCHA in the registration process:

1. Go http://www.adslgr.com/forum/register.php
2. Tick the box, submit
3. Click the CAPTCHA image. This should give you a new one.

I can confirm it doesn't work on adslgr.com, but it works fine on vbulletin.com.

With that header in mind and that it seems to be XmlHttpRequest based, perhaps it was from bug 362043 ?

Comment 23

[Scott MacVicar]

We've done a little more debugging and the site in question is returning "HTTP/1.1 501 Method Not Implemented" for any XHR action that is sent, I've tried to duplicate it locally but without any sort of success.

After some research this looks like older versions of mod_security (1.9) have a broken rule.

SecFilterSelective HTTP_Content-Type \
"!(^$|^application/x-www-form-urlencoded$|^multipart/form-data;)"

I obviously can't confirm this directly, the site in question would need to do this.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Mike, Scott, thank you very much for looking into this!  It's good to know that this is not a general vBulletin issue!

It does sound like the issue might be bug 362043.  And it sounds like this site just needs to be fixed.  Over to Tech Evangelism to contact them.

Comment 25

[Adam Guthrie]

I ran into what I think is the same problem in bug 396122. Anyway, this is the rule newer versions of mod_security are using:

SecRule REQUEST_HEADERS:Content-Type "!(?:^(?:application\/x-www-form-urlencoded(?:;(?:\s?charset\s?=\s?[\w\d\-]{1,18})?)??$|multipart/form-data;)|text/xml)"

They added this fix to the rules on 2007-05-02, according to the changelog. So, I guess this is "fixed". 

I still think this is a major issue, however, as everyone is not going to be running the latest version of mod_security...