Closed
Bug 782683
Opened 12 years ago
Closed 10 years ago
Image upload broken on Firebug wiki (SSL connection error)
Categories
(Infrastructure & Operations Graveyard :: WebOps: Other, task, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: Honza, Assigned: nmaul)
Details
(Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/86] [triaged 20120831][waiting][upgrade-feedback][firebug-p1])
When uploading a new image to Firebug wiki I am seeing: https://getfirebug.com:80/wiki/index.php/Special:Upload Secure Connection Failed An error occurred during a connection to getfirebug.com:80. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) As a test case, just try to upload an image here: https://getfirebug.com/wiki/index.php/Main_Page Honza
Reporter | ||
Comment 1•12 years ago
|
||
Just marking as p1 since we are not able to make documentation. Honza
Whiteboard: [firebug-p1]
Reporter | ||
Comment 2•12 years ago
|
||
The problem seems to be related to the URL which is used after the submit button (on the upload page) is clicked. It's: https://getfirebug.com:80/wiki/index.php/Special:Upload If I change it (using Firebug) to: https://getfirebug.com/wiki/index.php/Special:Upload It works. Honza
Comment 3•12 years ago
|
||
I am looking into this
Comment 4•12 years ago
|
||
This seems like something Mediawiki is doing. I am digging into why
Assignee: server-ops-webops → bburton
Status: NEW → ASSIGNED
Reporter | ||
Comment 5•12 years ago
|
||
Hi, any progress on this one? It's really annoying for the Firebug team. Honza
Comment 6•12 years ago
|
||
(In reply to Jan Honza Odvarko from comment #5) > Hi, any progress on this one? > It's really annoying for the Firebug team. > > Honza This seems to be coming from Mediawiki but neither :jakem nor I could find a setting that would correlate nor a bug report that matches. This wiki is currently on https://getfirebug.com/wiki/index.php/Special:Version - 1.16.5 and 1.19.2 is the current stable version, http://www.mediawiki.org/wiki/Download We'd like to schedule a time to upgrade to the latest stable version and see if that corrects the issue, we can do this on the dev site first, but want to coordinate some testing, what would be a good time to schedule this?
Assignee: bburton → server-ops-webops
Priority: -- → P3
Whiteboard: [firebug-p1] → [triaged 20120831][waiting][upgrade-feedback][firebug-p1]
Comment 7•12 years ago
|
||
When you're planning to update the wiki, please also consider to implement bug 631022. For me a good time for testing would be 9-10am PDT. Just leave me a mail if that fits you. Honza, if you want to test it, feel free to make a time suggestion. Sebastian
Reporter | ||
Comment 8•12 years ago
|
||
(In reply to Brandon Burton [:solarce] from comment #6) > (In reply to Jan Honza Odvarko from comment #5) > > Hi, any progress on this one? > > It's really annoying for the Firebug team. > > > > Honza > > This seems to be coming from Mediawiki but neither :jakem nor I could find a > setting that would correlate nor a bug report that matches. > > This wiki is currently on > https://getfirebug.com/wiki/index.php/Special:Version - 1.16.5 and 1.19.2 is > the current stable version, http://www.mediawiki.org/wiki/Download > > We'd like to schedule a time to upgrade to the latest stable version and see > if that corrects the issue, we can do this on the dev site first, but want Great, thanks! > to coordinate some testing, what would be a good time to schedule this? I am based in GMT+1 (+1 daylight saving time currently) and anything between 1am - 10am PDT is fine for me. Honza
Comment 9•12 years ago
|
||
:jakem is checking with OpSec on bug 631022 , do you want us to block doing the base upgrade on these plugins?
Comment 10•12 years ago
|
||
No, the image upload is more important than the plugins. I assume all of them can also be added afterwards, no? Sebastian
Comment 11•12 years ago
|
||
Hello everybody, This bug has been sitting around for a while, therefore I'd like to execute on one of the two following options : 1. Establish the clear and quantifiable steps that will allow this bug to be closed. 2. Close the bug for now and call it a day. Please comment at your earliest convenience. Thank you. :)
Flags: needinfo?
Comment 12•12 years ago
|
||
Hi Daniel, I don't understand what you mean by "Establish the clear and quantifiable steps" nor "call it a day". Fact is, this is still broken. If you need steps to reproduce it, here they are: 1. Log in to https://getfirebug.com/wiki/ 2. Go to https://getfirebug.com/wiki/index.php/Special:Upload 3. Click the "Upload file" button (or check the form's URL). The MediaWiki still didn't get updated yet. So it would be great if someone could finally take care of that, which hopefully fixes this bug. Sebastian
Flags: needinfo?
Comment 13•12 years ago
|
||
Hi Sebastian, So upgrading MediaWiki is the clear and quantifiable step necessary in order to close this bug - that's fine. :) As you can see, :jd has set up a blocker bug, which covers the upgrading of our MediaWiki instances in general. Thanks for your reply - have a great day !
Comment 14•12 years ago
|
||
> So upgrading MediaWiki is the clear and quantifiable step necessary in order to close this bug Ah, now I understand. :-) > As you can see, :jd has set up a blocker bug, which covers the upgrading of our MediaWiki instances in general. I am not authorized to see that bug but thanks for the info. Have a nice weekend! Sebastian
Updated•11 years ago
|
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Updated•10 years ago
|
Whiteboard: [triaged 20120831][waiting][upgrade-feedback][firebug-p1] → [kanban:https://kanbanize.com/ctrl_board/4/86] [triaged 20120831][waiting][upgrade-feedback][firebug-p1]
Assignee | ||
Comment 15•10 years ago
|
||
This is resolved (finally). Turned out to be a Mediawiki setting- it attempts to detect if HTTPS is set or not, and set the $wgServer variable based on this. It also attempts to detect non-standard ports, and add them if necessary. In our setup, SSL is offloaded by the load balancers so it doesn't get detected properly. The end result is it decides the proper server name is: https://getfirebug.com:80 Which clearly won't work (:80 is for http, not https) The fix is to simply specify $wgServer in the LocalSettings.php (or in this case, I used LocalSettings-local.php).
Assignee: server-ops-webops → nmaul
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 16•10 years ago
|
||
By the way I uploaded a file to test this, but don't to have access to delete it: https://getfirebug.com/wiki/index.php/File:HbWj.png
Comment 17•10 years ago
|
||
I can confirm that it works now. Thanks a lot for the analyses and the fix, Jake! I also deleted your test image. Sebastian
Updated•5 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•