FWIW this affected us as well, we switched from cloudflare back to cloudfront and hit this snag. The default settings do not forward Host header, we had to add that ourselves. Didn't need to change anything else, though - it seems that cloudfront performs loose SSL validation and is OK with the certificate/host mismatch. (Maybe it at least requires the host to match the origin domain - not sure.)

I've also made these additional changes, not directly related to the original request:

I think this is mostly guidance I neglected to issue, sorry about that.

Thanks! D17162 should clean this up.

These changes are now available in HEAD of master, and should be available on stable after Jan 13. master is also safe to upgrade into right now, although some T11114 stuff may churn later this week.

All evidence points to this and T9548 being the same task, right? I'm just going to merge them.

I believe there's more to it than just the bundle2 setting that causes it to not work. It still breaks for me even with devel.legacy.exchange=bundle1:

I have restarted httpd. I try to disable some chrome extension. Now it works.

Move all cards in this column to <another column>

That would be very useful for us as well.

I also can't reproduce this locally or on a Phacility test instance.

I can't reproduce the issue you describe following your steps on this server. Do you have any suggestions on what I could do differently to reproduce the bug?

official website click related "Close As Duplicate", browser send two request.

Started building and insanely easier as an application. "Favorites" unless you have a better suggestion. Seems more flexible.

In T10382#191728, @durin42 wrote:

For now, I'd suggest that if phabricator breaks bundle2, filter the response to the capabilities command and omit bundle2=.* from the response.

To be clear my suggestion was only for using 3.4 from client machines. Server machines can still be kept up to date.

Note that my suggestion in https://secure.phabricator.com/T10382#191728 is still what I think /should/ happen: if Phabricator insists on trying to parse the Mercurial protocol, it should absolutely not include capabilities it doesn't understand when queried by the client.

Running vanilla Mercurial 3.4 should not be recommended as all vanilla versions older than 3.7.3 are vulnerable to a trio of CVEs, the most likely exploitable being CVE-2016-3630. Instead, Mercurial <4.0 can be configured to disable bundle2 via the experimental.bundle2-exp=false config option and Mercurial >=4.0 can do the same via devel.legacy.exchange=bundle1. Both of these options are undocumented. I discourage their use. But as a workaround for Phabricator, they are preferred to exposing clients to known security bugs.

After reviewing the state of the world in related tasks:

Voila.

I'm going to merge this into T12074. Summarizing things so far and my short-term plans:

For T5214 / T12074, I am moving forward with an API query model where columns are associated with another, different object as a boardPHID (currently, always a project), and boards do not have their own objects or PHIDs.

You can also safely cherry-pick that to test if it resolves things, it doesn't interact with anything else.

That is: rP65c1c758ed261f65c8164d200ce01373ae5b822c

If you upgrade past 65c1c758ed261f65c8164d200ce01373ae5b822c (both stable and master have this change), does it reproduce?

(And again, to emphasize, I'm happy to drop this if y'all aren't interested. I have my solution and am happy ignoring this, but just thought it might be something you guys would want to check out.)

Head as of my Dec. 17 post in this thread. Can roll forward, but was hoping to wait till the edit engine migration settled a bit.

What version of Phabricator are you currently running?

@epriestley any suggestions?

The *.search endpoints are preferred now, but the guidance we provide on the Conduit page could use some updating. I'll rework this a little alongside other changes here.

I'm sorry you found this interaction frustrating. How would you prefer we have handled it?

Thanks for the warm welcome to the community

The Phacility cluster is on 2017 Week 1 now and I can't reproduce this there, either:

Thanks for the report! We were just missing a "/" (Quicksand does not follow redirects, which I think is desirable, although maybe we'll change that eventually) but D17151 should fix this up a little more robustly.

Specifically, here's what I believe the bug is, in rough terms that probably get some specifics wrong:

This can either move forward as a bug report or a consulting request.

It was installed from a FreeBSD package

Sorry for wasting your time. For the record:

.mov thing is likely an interaction between range requests and encryption. It works for me in Firefox. It only affects media files for installs which have configured file encryption and there's no data corruption/loss so I don't plan to get to it for a while unless a real install hits it.

ok forget it. works fine in other browser.

Chad's House ?

How do I reproduce that?

@epriestley maybe also related? Some files are just missing in Conpherence now.

I am currently using project.query rather than project.search. I presume the change you suggest for .search would work for query too since my recollection is that project.query also doesn't return milestones. I tried to use .search originally, but noticed that the attachments available were limited and didn't correspond to the documentation (examples mentions projects, subscribers, but then later on only watchers and members are supported) so I was scared off by the 'may change' warning:-) I can switch to using .search if that's the better thing to do - I presume you'd add attachments for the new types of information to be returned?

My misunderstanding on this btw, I assumed mov was an option, not a default.

Anywho, I can't reproduce this in a local sandbox or on Phacility, so assume something is hokey with how files are served maybe in secure.

My expectation per Contributing Bug Reports is people submit bug reports they see on their real install. Otherwise we have no idea now to prioritize if something happened here testing vs. something people really hit in day to day use. Filing it here also means an upstream developer must respond to it.

I expect it to work, because it looks like it is supposed to:

And I think most people can't play them.

Why do you expect mov's to work? To my knowledge, this server isn't configured to support them.

I did some further digging and made a little progress

Yeah, this is in stable, just didn't make the cut for individual mention in the changelog. I think it promoted in Week 52 and I just lumped it into "Differential got infrastructure changes".

Sorry! Will do.

Please use your own install or a Phacility instance to test Phabricator. I appreciate that you're finding bugs, but this is our real install, not a demo.

Ah ok