Thank you for the response.

@ChristopherHJohnson the problem is that it isn't "just one change", we get requests in this vein several times a day and without a clear line on what "free support" looks like, the Phabricator project does not move forward. We just aren't staffed to manage these requests in any sort of reasonable timeframe. "Wishlist" items at best are 2-3 years out. We'd rather be honest about what the upstream can and cannot do in a reasonable timeframe so you have time to explore alternatives.

I am not asking for "support" per se, so I am not sure the referenced link is applicable for this task.

I am not asking for "support" per se, so I am not sure the referenced link is applicable for this task. The use case of application/json requests is major, so rejecting it outright as some kind of non-essential fringe "custom code" seems rather strong. The problem is pretty simple and the fix even more so. I am asking you to consider the benefits of parsing a specific content-type request with an appropriate parser. I totally understand that you have priorities, etc., but this is the situation with my team. We have code on GitHub and associated build tools that will probably never move to Phabricator. How can I not consider the need to integrate these "third-party" tools seriously? I am open to suggestions. Worst case scenario is that we maintain a patched version of this class, which for such a trivial change seems ridiculous.

See also:

Sorry, we do not support third-party application development. See T5447 for discussion.

Sorry, we don't offer support with third-party custom development. See "Supported Issues" here:

i had a lot of projects created before, but starting from today's update, can't create anymore.
And yes, i checked and had exactly the same code .

I can not reproduce this.

Let us know if restarting didn't resolve this. Thanks!

Can you try restarting apache (or php-fpm) and see if that resolves this issue?

Awesome, thanks for testing! We'll get this upstreamed shortly.

Oh no, its not a silly question :D Sorry, i justy quickly look this patch and totally forget restarting web-server... It works lik a charm ;) Thanks.

Probably a silly question, but did you restart Apache or php-fpm after applying the patch?

Applyed this diff to my local install but does not seems to be helped. The trace, and the throwed exception is the same as before.

Pretty sure D13095 will fix this.

Do you have a full stack trace in your error log? Usually /var/log/apache2/error_log or something like that, depending on exactly which webserver/OS you're running.

I've removed this error completely (see rPHUbd087f55).

Ah, perfect.

OoOoO, great tip.

Just doing phlog($ex) might be useful (or phlog(new Exception()) if you aren't actually catching one).

I have to walk the dog so I will be afk 20ish minutes but this will be what I am working on when I get back.

Basically got useless stuff like the below

Error logs are quiet. I put in a phlog(debug_backtrace()) and played with print_r but its hard to get a lot of text out of phlog?

I can't immediately reproduce this -- do you have a trace in the Apache/php-fpm error log?

FWIW, I'm seeing this roughly 60 times per day in our error logs.

Hi, I'm not sure how Phabricator handles compatibility libraries but PHP has http_response_code() available which sets the status code and message in one go. The fix for this task could be introduced as a compat method for PHP < 5.4.

Oh right. I would've expected a 302 to /auth/login/ or similar.

This is intentional. This is a login page, not a 404. We don't 404 logged-out users because we don't want to disclose the existence of applications.

I might give this a go.

Specifically, in the screenshot shown, the response is shown as 404 OK instead of 404 Not Found.

I think this is desirable, it's just kind of a pain to implement:

The SiteConfig mechanism might let us get away without really taking this too far, since it acts really early in the stack and can sort of end run around the handling here. I expect I'll push this forward a bit more but probably not get it to a really polished state before launch.

@chad, yes it is.

@joshuaspence, is this still occurring?

In T1806#67907, @epriestley wrote:

When a component moves, apply any breaking API changes or generalizations that it should have to be general-purpose. An example is that I think willProcessRequest(array $data) + processRequest() was probably a mistake. A better signature would be processRequest(AphrontRequest $request, array $route_data) -- or even making the route data a property of $request -- because 99% of willProcessRequest() methods just copy route data to properties, and 90% of processRequest() methods begin with $request = $this->getRequest(). Another example is that AphrontRequest->getUser() should probably be AphrontRequest->getViewer().

We need this, at a minimum, to unblock host-based configuration. We might need some more work after this, too.

I'm change phabricator/.devinercache owner
and exception don't appear.

In T5816#7, @epriestley wrote:

Can you show us the output of this command?

phabricator/ $ ./bin/storage upgrade

`$ ./bin/storage upgrade
Before running storage upgrades, you should take down the Phabricator web
interface and stop any running Phabricator daemons (you can disable this
warning with --force).