After upgrading to Laravel 8.9 from 7.x, Laravel returns the wrong status code when requesting a non existing model. The response body itself contains the expected error response, however the status code is 200. Here is the corresponding controller code:
public function findOne($eventId)
{
$event = Event::withMailRecords()->withContacts()->withContingents()->findOrFail($eventId);
return new EventResource($event);
}
I only get the wrong status code when starting the server using php artisan serve and then execute our frontend tests to query the server. Within our Laravel HTTP tests, everything works fine. Moreover, the issue only appears within our bitbucket ci pipeline. Locally everything works fine, even when executing the tests within our pipeline image.
I cannot see any environment differences that could possibly result in this behavior.
Maybe this is not the source of your problem, but are you sure there is no space before any "<?php" tag or that you are not using encoding like UTF8 with BOM that would have already sent headers ?
Related
I'm new to laravel and I'm building a pure laravel 9 app(no vue, nodejs or other frameworks just laravel + vanilla js). If I have any kind of error in any laravel view/component/partials the error page response tooks more then 20seconds to appears. If I have an error in any controller/model/config or other laravel's environment files, the same error is superfast. In example if I have a typo in my view layout.blade.php
PHP
#php
ech 'missing a letter';
#endphp
this will throw the error in 20 seconds
if I place a typo in a controller like this
PHP
public function index() {
retur 'missing a letter';
}
this will throw the error instantly.
if this can helps, checking in my console the laravel log file like this
DEBIAN BASH
tail -f /var/www/mylaravelapp/storage/logs/laravel.log
will throw the error in the same time that appears in the laravel error page.
Obviuously is not a big deal, but since I'm working on the appareance of the UI, this will slow down my work so much.
UPDATE
I'm adding a screen of my devtools opened, it simply waits for server response 23 seconds
UPDATE
Some new details, really strange for me, what happens is that in my component I have some pure javascript script in the bottom of the page(around 500 rows). If I delete the scripts the error page will run superfast. I tried to place the scripts directly behind the scripts tags and I tried using the #pushOnce directive with same results. I tried to reduce the amount of code, and the more I reduce the code the more will run faster. I tried to put the script directly in my layout.blade.php that calls the component and it runs superfast, I tried to put the js code like an external script and it runs superfat, so problem happens only with inline JS probably I'm placing the scripts in a wrong way
UPDATE
OK I think this update is important, if I run my laravel app through my apache web server(so not using php artisan) the error page will load superfast, so this cannot be related to some code error. Usually I run my laravel app in this way
php artisan serve --host 192.168.25.209
where 192.168.25.209 is a server in my network that is hosting my laravel app. As #Don't Panic pointed in the comments
"The web server runs only one single-threaded process, so PHP applications will stall if a request is blocked"
So I checked for permissions on cache storage folders, but everything looks good, cache files and logs are correctly written
I use Laravel 5.5 and I have Controller like this.
use Illuminate\Support\Facades\Artisan;
---------------------
public function index()
{
Artisan::call('config:cache');
}
but it not work correctly and show me this message in browser:
This site can’t be reached
The connection was reset.
Try:
Checking the connection
Checking the proxy
the firewall
Running Windows Network Diagnostics
ERR_CONNECTION_RESET
It already worked but it not work correctly now.
Note1: All commands in Artisan dose not work, for example migrate,seed,...
Note2: I install another laravl 5.5 script and test Artisan::call method and it work correctly but it dose not work correctly in my script.
hope you're good
I was trying to add a profile table to my Laravel 5.6 project, and I'm also using the spatie\Laravel-Permission package. It was working fine, but after I ran some migrations (that have nothing to do with users), it started failing on the login. The curious thing is that, if I register a new user, it gets logged in properly, but never with the /login route (I'm using the Laravel's Auth scaffolding).
After debugging the project, I came up with the method that's failing, it's something reading the sessions:
MyProject\vendor\laravel\framework\src\Illuminate\Filesystem\Filesystem.php
<?php
namespace Illuminate\Filesystem;
use ErrorException;
use FilesystemIterator;
use Symfony\Component\Finder\Finder;
use Illuminate\Support\Traits\Macroable;
use Illuminate\Contracts\Filesystem\FileNotFoundException;
class Filesystem{
// ...
public function get($path, $lock = false)
{
if ($this->isFile($path)) {
return $lock ? $this->sharedGet($path) : file_get_contents($path); // <-- The failing line
}
throw new FileNotFoundException("File does not exist at path {$path}");
}
// ...
}
Once it gets to that line, the debugger stops, the browser doesnt get a response, the dd() function does not get triggered... I also tried to debug the sharedGet($path) method, and it returns the value, but back to the method above, it stops.
Also, the php_error.log file gets absurdly increased on every request (up to 500MB/request), so much that none of the editors I use can open it (SublimeText, NetBeans).
My thoughts are that apache may be running out of memory when reading the files, but the session file barely weights 1k, so it wouldn't make much sense.
Can someone throw any clue? Thanks
--EDIT:
I tried installing a fresh laravel proyect with only the Auth module and the spatie/laravel-permission package, and I noticed the same behaviour: it registers and logs users, but after logging it out, I'm no longer able to log in with any user.
In case someonw gets to the same error:
I could manage to solve this by backing up all my projects/databases and reinstalling wampserver with the last version of php (by the moment of this answer, it is 7.2.4) and reinstalling Laravel (luckily the proyect was barely starting), which only updated vlucas/phpdotenv package from 2.4.0 to 2.5.0 and phpunittest.
Whith this update now I can log in users normally, now let's see if it works as it should with spatie/laravel-permission package and the profile table I need to add.
I have build a REST server and trying to make my java application communicate to it.
But I keep getting a 404 error.
When I type in the url in my browser along with the function name like:
[url]/controller/functionname/1.json
it works fine, returning me the right data.
Without the function name:
[url]/controller/1.json
I get this error:
"action 1.json not defined in controller".
I've checked my .htaccess file and routes against a previous version I had build which was working just fine. I can't figure out what the problem might be. Any suggestions?
And oh, I should mention, the earlier version that I talked about was build on windows and this one on ubuntu.
I have a Magento 1.6.2 site hosted on 1&1. Because of certain installed extensions I must have support for PHP version 5.3, but sadly the available options with 1&1 are PHP 5.2 or something they call PHP Dev. A quick phpinfo() shows that this is in fact PHP 5.4.
My problem is that when I'm set to 5.4, the Categories page of the backend throws a 500 error. Rolling back to 5.2 fixes the issue, but that breaks my product pages. In the short term I can handle having to swap between them, but this is obviously unacceptable for a long-term solution when the site is handed to the client.
Can anyone suggest where this incompatibility might lie, and what steps I might take to fix it? My biggest impediment is that the hosting is on a shared server, and so I am not allowed to look at the Apache logs.
Update:
As per CCBlackburn's suggestion in the comments, I have tried to track the point that the error originates from, but I have to admit that I don't really understand the results I'm getting. The URL of the categories page looks like this:
example.com/index.php/admin/catalog_category/index/key/blahblah
I presumed that Mage_Adminhtml_CatalogController would be the place to start looking, but a Mage::log() call as the first line in indexAction() failed to write to the log.
I decided to move up the inheritance and cut into the constructor, and so added the following to Mage_Adminhtml_Controller_Action:
function __construct(Zend_Controller_Request_Abstract $request, Zend_Controller_Response_Abstract $response, array $invokeArgs = array()) {
Mage::log('construct pre');
parent::__construct($request,$response,$invokeArgs);
Mage::log('construct post');
}
This was better, as the first log call wrote to the file, but the second did not.
Next I moved up the inheritance again, and modified the constructor of Mage_Core_Controller_Varien_Action as follows:
public function __construct(Zend_Controller_Request_Abstract $request, Zend_Controller_Response_Abstract $response, array $invokeArgs = array())
{
Mage::log('request: '.$request);
$this->_request = $request;
Mage::log('response: '.$response);
$this->_response= $response;
Mage::log('pre set action');
Mage::app()->getFrontController()->setAction($this);
Mage::log('post set action');
$this->_construct();
}
The problem is that none of these log calls do anything. This has me stumped, as surely calling parent::__construct(); from Mage_Adminhtml_Controller_Action should execute at least one more log call before it does anything. Unless the issue exists with the incoming values, but I don't know how I can check/debug that?
I have faced the same problem under OSX Lion in Google Chrome and Apple Safari with Magento 1.7 and PHP 5.4. Suddenly Magento Category admin started giving 500 Errors and I had no clue what was happening. It seems it's a problem with PHP 5.4. At first I thought it was XDebug causing this error. Then I disabled XDebug and the problem was still there. It is weirder than weird that it works with Firefox!
My solution was to downgrade to the latest PHP 5.3, however this has now been fixed as of PHP 5.4.3.