Closed
Bug 785326
Opened 13 years ago
Closed 13 years ago
"504 Gateway Time-out" error when adding a new review containing a long word
Categories
(Marketplace Graveyard :: Consumer Pages, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
2012-11-08
People
(Reporter: cboldan.mozbugs, Assigned: basta)
References
Details
(Whiteboard: [janus])
Steps to reproduce:
1. Load Marketplace homepage https://marketplace-dev.allizom.org/
2. Click on a free app to load details page
3. Click on "Submit a review" button
4. Add a review containing a long word (ex. a word formed of 40 characters)
Expected results:
User is redirected to the reviews page and the review is added.
Actual results:
"504 Gateway Time-out" error is displayed on a blank page.
Notes/Issues:
Verified in FF17 (Win 7).
Screencast for this issue http://screencast.com/t/hygg6Mf8po
Comment 1•13 years ago
|
||
I can totally reproduce this, much to my unending dismay.
Comment 2•13 years ago
|
||
Reviews are broken right now so I can't verify (bug 798347) but this is definitely weird.
Priority: -- → P3
Comment 3•13 years ago
|
||
(In reply to Wil Clouser [:clouserw] from comment #2)
> Reviews are broken right now so I can't verify (bug 798347) but this is
> definitely weird.
This is still a thing
Assignee | ||
Comment 4•13 years ago
|
||
I can reproduce this bug for reviews, but not for replies. That means that the code most likely lives in mkt.ratings.forms.
Assignee | ||
Comment 5•13 years ago
|
||
If I'm not mistaken, this is caused here:
https://github.com/mozilla/zamboni/blob/master/apps/reviews/forms.py#L41
The regex that we're using to test if links exist is very, very greedy. Basically it seems to get stuck in an exceedingly long pattern that tries to match groups of strings over and over and over, but only finds out once it gets to the end that it's not a URL and tries matching from the next character.
If this is the case, my vote is to test only for URLs that have an ((ht|f)tps?:)?// prefix or a numeric IP address OR to have the pattern updated to only match URLs that bleach will linkifiy automatically. As it stands, this regex seems to be too inefficient.
Can someone confirm this locally?
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → mattbasta
Comment 6•13 years ago
|
||
I can confirm it takes longer than it should. I used the string, "this is a very long word: supercalifragilisticexpeallidocious" and that regex alone took 8 seconds to search the string.
Comment 7•13 years ago
|
||
Good catch, basta. Importing/using bleach is a good idea.
Assignee | ||
Comment 8•13 years ago
|
||
I'll do you one better:
https://github.com/mozilla/zamboni/commit/d939d3ca8ae7a51c814f13abd797399a31017987
This makes the current test more generic (it'll catch more TLDs than bleach) and it's at least an order of magnitude faster. We'd also have to write some icky stuff, as it turns out, since bleach's regex pattern parses only links with a protocol on them. This saves a lot of hassle and code has been shipped. :)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2012-11-08
Reporter | ||
Comment 9•13 years ago
|
||
Verified as fixed in https://marketplace-dev.allizom.org/ on FF19(Win 7)
Postfix screencast http://screencast.com/t/CZssbEuBGf
Closing bug.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•