I am quite new to Django, and I hope my question is not too silly. I am currently running my project locally, and each time I do an API call with the browser, I see the server log something similar:
my_table | [08/Jan/2023 20:20:42] "GET /static/rest_framework/css/default.css HTTP/1.1" 404 179
my_table | [08/Jan/2023 20:20:42] "GET /static/rest_framework/js/bootstrap.min.js HTTP/1.1" 404 179
my_table | [08/Jan/2023 20:20:42] "GET /static/rest_framework/js/jquery-3.5.1.min.js HTTP/1.1" 404 179
my_table | [08/Jan/2023 20:20:42] "GET /static/rest_framework/js/csrf.js HTTP/1.1" 404 179
my_table | [08/Jan/2023 20:20:42] "GET /static/rest_framework/js/ajax-form.js HTTP/1.1" 404 179
my_table | [08/Jan/2023 20:20:42] "GET /static/rest_framework/js/default.js HTTP/1.1" 404 179
my_table | [08/Jan/2023 20:20:42] "GET /static/rest_framework/js/prettify-min.js HTTP/1.1" 404 179
There are a tons of static files that are served via the API. If I do the same with Postman or similar, here is the log:
my_table | [08/Jan/2023 20:25:12] "GET /api/v1/category/ HTTP/1.1" 200 2
It looks like it only sends the response I wanted, via JSON or whatever. I was wandering if there is a way to prevent Django from serving static files at all, since I will only use the Rest Framework, or maybe gRPC in the future, but never static files. I tried to delete the static file constant from settings, and then nothing worked anymore, so I was wandering if there is something I need to do in order to achieve this goal. Thank you for your help
It is pretty simple. You go to the installed APPS,and you will find something like:
BASE_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]
Delete the one with django.contrib.staticfiles, and then you can delete also the static files root variables
I'm pretty new to AWS Amplify and I'm trying to deploy an app with my own frontend and backend, I have successfully deployed the frontend but I can't figure out how to connect the backend (it seems like the server is not responding).
Here's my project structure:
And Here's my amplify.yml
version: 1
frontend:
phases:
preBuild:
commands:
- npm ci
# IMPORTANT - Please verify your build commands
build:
commands: []
artifacts:
# IMPORTANT - Please verify your build output directory
baseDirectory: 'client'
files:
- '**/*'
cache:
paths:
- node_modules/**/*
I got a warning on the website:
Failed to load resource: the server responded with a status of 404 ()
I also tried adding the code below to the yml
version: 1
env:
variables:
key: value
backend:
phases:
build:
commands:
- amplifyPush --simple
But the application failed when building
Not sure if this has something to do with using express.js in node.js
I've been having troubles with getting gitlab to send jobs to sonarqube. I have installed the sonarqube plugin and added my gitlab user token to the sonarqube server. In my gitlab-ci.yml I run the following command:
- git config --global user.email "$GITLAB_USER_EMAIL"
- git config --global user.name "$GITLAB_USER_NAME"
- cd /opt
- wget -q https://sonarsource.bintray.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-3.2.0.1227-linux.zip
- unzip -qq sonar-scanner-cli-3.2.0.1227-linux.zip
- cd /builds/my_user_name/my_project/backend
- /opt/sonar-scanner-3.2.0.1227-linux/bin/sonar-scanner -X -Dsonar.host.url=http://34.230.xx.xx -Dsonar.projectKey=$CI_PROJECT_NAME.develop -Dsonar.projectVersion=$CI_COMMIT_SHA -Dsonar.gitlab.url=https://www.gitlab.com -Dsonar.gitlab.project_id=$CI_PROJECT_ID -Dsonar.gitlab.user_token=$SONAR_PLUGIN_TOKEN -Dsonar.gitlab.commit_sha=$CI_COMMIT_SHA -Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME -Dsonar.analysis.mode=preview -Dsonar.sources=.
The error I get is the following. I get this error both with using the npm sonarqube-scanner as well. Does anyone know what is going on?
05:12:15.795 DEBUG: * GitLab 3.0.0 (gitlab)
05:12:16.171 INFO: Process project properties
05:12:16.184 DEBUG: Process project properties (done) | time=13ms
05:12:16.199 INFO: Load project repositories
05:12:16.227 DEBUG: GET 404 http://34.230.xx.xx/batch/project.protobuf?key=my_key_here&issues_mode=true | time=25ms
05:12:16.229 DEBUG: Project repository not available - continuing without it
05:12:16.234 WARN: Project doesn't exist on the server. All issues will be marked as 'new'.
05:12:16.235 INFO: Load project repositories (done) | time=36ms
05:12:16.314 INFO: Scanning only changed files
05:12:16.317 INFO: Execute project builders
05:12:16.999 INFO: ------------------------------------------------------------------------
05:12:17.006 INFO: EXECUTION FAILURE
05:12:17.007 INFO: ------------------------------------------------------------------------
05:12:17.008 INFO: Total time: 4.682s
05:12:17.050 INFO: Final Memory: 11M/104M
05:12:17.051 INFO: ------------------------------------------------------------------------
05:12:17.052 ERROR: Error during SonarQube Scanner execution
java.lang.IllegalStateException: Unable to load component class org.sonar.scanner.scan.ProjectLock
at org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer.getComponent(ComponentContainer.java:64)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:678)
at org.sonar.core.platform.ComponentContainer.getComponentByType(ComponentContainer.java:265)
at org.sonar.scanner.scan.ProjectScanContainer.doBeforeStart(ProjectScanContainer.java:120)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:133)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.task.ScanTask.execute(ScanTask.java:48)
at org.sonar.scanner.task.TaskContainer.doAfterStart(TaskContainer.java:84)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:121)
at org.sonar.batch.bootstrapper.Batch.doExecuteTask(Batch.java:116)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:71)
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
at com.sun.proxy.$Proxy0.execute(Unknown Source)
at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:171)
at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:128)
at org.sonarsource.scanner.cli.Main.execute(Main.java:111)
at org.sonarsource.scanner.cli.Main.execute(Main.java:75)
at org.sonarsource.scanner.cli.Main.main(Main.java:61)
Caused by: java.lang.IllegalStateException: Unable to load component class org.sonar.scanner.scan.DefaultInputModuleHierarchy
at org.sonar.core.platform.ComponentContainer$ExtendedDefaultPicoContainer.getComponent(ComponentContainer.java:64)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:632)
at org.picocontainer.parameters.BasicComponentParameter$1.resolveInstance(BasicComponentParameter.java:118)
at org.picocontainer.parameters.ComponentParameter$1.resolveInstance(ComponentParameter.java:136)
at org.picocontainer.injectors.SingleMemberInjector.getParameter(SingleMemberInjector.java:78)
at org.picocontainer.injectors.ConstructorInjector$CtorAndAdapters.getParameterArguments(ConstructorInjector.java:309)
at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:335)
at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:270)
at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:364)
at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.getComponentInstance(AbstractInjectionFactory.java:56)
at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:699)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:647)
.....
Check your Sonar plugins versions, compared to your SonarQube version.
As in this thread, you would (for instance) be running SonarQube 7.1 with extensions made for SonarQube 7.0 (Branch, Developer).
The OP Coherent reports in the comments using:
docker run -d --name sonarqube -p 80:9000 -p 9092:9092 \
-e SONARQUBE_JDBC_USERNAME=x
-e SONARQUBE_JDBC_PASSWORD=y
-e SONARQUBE_JDBC_URL=jdbc:postgresql://mydatabase-east-1.rds.amazonaws.com/sonar sonarqube:7.0
Tibor Blenessy adds
Try to remove -Dsonar.analysis.mode=preview, this option is no longer supported.
Save the following HTML as a local file. Something like /tmp/foo.html, then open that in Firefox (I'm on 49.0.2)
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<script src="http://localhost:1234/a.js"></script>
<script src="http://localhost:1234/b.js"></script>
<script src="http://localhost:1234/c.js"></script>
<script src="http://localhost:1234/d.js"></script>
<script src="http://localhost:1234/e.js"></script>
</body>
</html>
I don't have a server running on port 1234, so the requests don't even successfully connect.
The behavior I'd expect here is for all the requests to fail, and be done with it.
What actually happens in Firefox is all 5 .js files are requested in parallel, they fail to connect, then the last 4 get re-requested in serial. Like so:
Why?
If I boot a server on 1234 that always 404s, the behaviour is the same.
This particular example doesn't reproduce the same behavior in Chrome, but other similar examples is how I originally fell upon this behavior.
EDIT: Here's how I tested this happens when it 404's as well.
$ cd /tmp
$ mkdir empty
$ cd empty
$ python -m SimpleHTTPServer 1234
Then reloaded Firefox. It shows this:
The server actually sees all those requests too (the first 5 arrive out of order because they're requested in parallel, but the last 4 are always b, c, d, e, since they get re-requested in serial).
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /d.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /c.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /b.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /a.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /e.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /b.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /c.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /d.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /e.js HTTP/1.1" 404 -
This has to do with edge-cases that could arise with parallel resource loading, where JavaScript is expected to block other resources from loading.
This behavior starts to get more-clear when you add a delay into the error responses. Here is a screenshot of the Firefox network panel with a 1-second delay added to each request.
As we can see, all 5 scripts were requested in parallel, as modern browser do, to reduce loading times.
However, except for the first one, those scripts that returned a 404 were re-requested, not in parallel but in series. This is almost-certainly to maintain backwards compatibility with some edge-cases with the legacy browser behavior.
Historically, a browser would load and execute one script at a time. Modern browser will load them in parallel, while still maintaining execution order.
So why might this matter?
Imagine if the first script request changed the application state, perhaps setting a cookie or something to authenticate further requests. With the new parallel loading, those scripts would be requested before this state was changed, and assuming the web application is well-enough designed, throw an error.
So the only way to ensure the other resources didn't error because the script did not have a chance to change the state before they were requested is to re-request the resources again.
In fact, this re-requesting behavior is not limited to just scripts, and can also be seen to effect images that error after a script tag that was loaded in parallel.
Potentially, because those images may have failed to load because a prior script did not execute first, they are all re-requested in parallel.
Interestingly, I can't find anything directly about this in the spec, but this section from The Living Standard suggests this behavior may actually violate the spec.
For classic scripts, if the async attribute is present, then the classic script will be fetched in parallel to parsing and evaluated as soon as it is available (potentially before parsing completes). If the async attribute is not present but the defer attribute is present, then the classic script will be fetched in parallel and evaluated when the page has finished parsing. If neither attribute is present, then the script is fetched and evaluated immediately, blocking parsing until these are both complete.
If parsing were actually blocked, then it would seem the following script tags and images should not have been read to be able to load. I suspect that the browsers reconcile this issue by not making the following tags available in the DOM until after execution.
Note:
The exact behavior you will see in these cases may vary a bit. Only those resources that were actually requested in parallel with a script will actually be reloaded. If an image afterwards errors, but it was not requested while a script was loading, then there is no need to re-request it. Additionally, it appears Chrome only triggers this behavior if the potentially-state-changing script does not error, however Firefox triggers this behavior even if it does error.
Code works absolutely fine but when Charles proxy running in background, I get following error in Chrome and Firefox. Charles proxy is running at default settings.
Uncaught Error: Load timeout for modules: jQuery,handlebars
http://requirejs.org/docs/errors.html#timeout require.js:8
F require.js:8
C require.js:13
(anonymous function)
OS: OS X 10.8.4
Charles: v 3.7
Chrome : 28.0.1500.71
Firefox : 22.0
Turns out the issue was related to hosts file. Requirejs was throwing timeout because localhost was taking too long to resolve. Everything works fine after updating hosts file to this:
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost.localdomain
127.0.0.1 localhost
127.0.0.1 username.lmuk.local
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
More information available here.