Open Bug 392046 Opened 13 years ago Updated 6 years ago

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

Categories

(Tech Evangelism Graveyard :: Other, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

People

(Reporter: patrickdrd, Unassigned)

References

()

Details

(Keywords: regression)

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.
Flags: blocking-firefox3?
Version: unspecified → Trunk
Keywords: qawanted
I can't read Greek, but maybe wgianopoulos@yahoo.com can (sounds like a Greek name).
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...
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.
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)
I can confirm the issue.  It only seems to effect quick reply.  Everything else seems to work.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Any idea on regression range?  Or just steps to reproduce?
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.

from first attempt to find a regression range i saw this regressed between
2007-05-09 (work) and 2007-05-15 (don't work)
Whiteboard: need 1-day regression range
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
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)
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
many thanks guys!
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?
Blocks: 116346
Component: General → HTML: Form Submission
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → form-submission
Flags: blocking1.9?
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
I would agree with marco
I just went to the vBulletin website into there test forum which uses vBulletin 3.6.8.  There is no Quick Reply.
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
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.  :(
Summary: can't post to a site (forum) with minefield → can't post to a vBulletin 3.6.8 site (forum) with minefield
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 ?
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.
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.
Assignee: nobody → other
Blocks: 362043
No longer blocks: 116346
Component: HTML: Form Submission → Other
Flags: blocking1.9?
Product: Core → Tech Evangelism
QA Contact: form-submission → other
Version: Trunk → unspecified
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...
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.