I created a test-event now, it starts in an hour, and I will take a look if this occurs again.

Okay, what version of Apache are you running? (httpd -v or similar may tell you.)

Heh, just ran into this today

No problem, thanks for the report!

Awesome, thanks @epriestley!

I've marked D16909 as fixing this, but it just removes mysql.implementation, and uses the rule "mysqli if available, mysql otherwise".

I think this should be fixed now. Note that we still have T11165 floating around which may make it look like this is still an issue, by sending you to the wrong place when you hit "Save". That bug is dumb but fairly harmless so I haven't chased it down yet.

Oh, hrrrm, this is actually more involved since it's not just the .git clone URI that's in trouble. So I can't just ban . without fixing existing short names.

Okay, let me ban them for now and if it causes too much of an issue we can try just banning .git at the end.

(From our own install's perspective) I don't think the would make anyone at all sad. It seemed to be a pretty random decision by one of our newer users while he was playing around with things.

(This is T6740, not T9979.)

This is because we now recognize shortname.git in some cases, and it's ambiguous if quack.git is "the repository with shortname quack.git", or "the repository with shortname quack, addressed as a Git repository".

I think this might be T9979 though.

Spin up a test instance on Phacility, build a reproduction case and update the ticket. We don't have any insights into how the server you mentioned is configured of administered. We can with Phacility instances if you can't install something locally.

@chad, thanks but isn't this an upstream bug? The example I gave downstream were of convenience. Do you need me to find an example upstream?

Please contact your administrator if you want to file a bug against Phabricator. I believe there is an area where you can file bugs for us to look into in the downstream.

Confirmed this on my local. It seems to be due to D16851, specifically this line: https://secure.phabricator.com/source/phabricator/browse/master/src/applications/diffusion/application/PhabricatorDiffusionApplication.php$104.

I've marked D16905 as resolving this: we now recommend a minimum value (33554432).

Although it's very possible that this is a bug, this state also has a 72-hour internal cache which wasn't written correctly in older versions of Phabricator.

Can you show me the <VirtualHost> entry you've added for Phabricator in your Apache config? I suspect you may have omitted the B flag in the RewriteRule.

Phrequent is a prototype, and we don't accept bug reports for prototypes. See User Guide: Prototype Applications for discussion.

I tried the openssl connection you suggested and it still bombed.

What about Node.js v0.10 and v0.12?

If you're still currently using Node.js v0.10 or v0.12, it is time to begin the transition to v4 or v6. Both v0.10 and v0.12 are considered to be in Maintenance mode currently and will fall off our support plan completely later this year.

Great thanks!

This should now be fixed in HEAD of master and stable.

Cool. D16901 should fix this properly. Thanks for the report!

Fixed and I'm back up and running, thanks!

I can confirm that SHOW TABLES IN phabricator_xhpast works just fine as root mysql user, and dropping the credentials from the upgrade command yields exactly the same results as running under root. So that seems like it all ties up. I can work around this any number of ways and I will do just that.

Yeah, looks like some credential shenanigans are afoot. I instrumented the user we're actually connecting as and am getting a mixture of what I passed with -u ("trunk") and the default user ("root").

Maybe also: do you have cluster.databases configured?

If you run this from mysql directly, as root, does it work?

I can't reproduce this.

This report is missing required information.

Yeah, these aren't the rules from our guide. If you want help please do the following:

Did you follow our installation guide, or did you follow a third-party installation guide (for example, a blog post you found somewhere on the internet)?

Oh, sorry, I meant: if security.alternate-file-domain was configured, that prevented this problem.

Well, I do not have configured the security,alternate-file-domain.
But it works now for me with this fix :D

I'm reasonably sure that fixes it; let us know if you're still seeing issues after updating.

(This likely would not be reproducible on any instance which has security.alternate-file-domain configured, which is why it wouldn't reproduce here or in the Phacility cluster.)

This reproduces somewhat-reliably for me with Quicksand (Persistent Chat) on.

You are right, I also can't reproduce it on the Phacility instance. I really don't know what do do next ^^

Please take the time to try to reproduce the issue on a Phacility instance, and report back if you can. We have not been able to reproduce the issue with these set up steps. Reproduction steps must includes everything we need to review and fix the issue locally.

Or we already have a task on it. Either way.

This is expected, we merge no information over when you close a task as a duplicate.

It works, thank you!

Thank you, that was a very quick resolution, I just had the time to refresh the page !