I include my CSS files in the header:
<link rel="stylesheet" type="text/css" href="http://cdn.website.com/base.css">
In the S3 interface under Properties-->Metadata-->
Key: Content-Type
Value: text/css
Permissions are granted to Everyone with Open/Download
Still not working.
The problem is determining the path to the static content of the application (it depends on path the application starts olso)
Solutions are:
Start application from root application path
example: ApplicationName path=/home/ec2-user/site then need
cd /home/ec2-user/site && ./ApplicationName
Configure path for method .UseWebRoot(path_to_static_content)
Related
I'm using nginx in a docker container which is serving out static content. It's run in Kubernetes as a sidecar to another service in the same file.
However, the issue is that although the same exact HTML page is being served (I checked using a text comparer) the page looks malformed on the web server (but fine when I render it locally)
So because of this, it makes me think that there is an issue with serving some of the css, js, or image files
Here's part of the Kubernetes deployment
containers:
- image: <OTHER IMAGE>
imagePullPolicy: Always
name: <imagename>
ports:
- containerPort: 8888
- image: <MY NGINX IMAGE>
imagePullPolicy: Always
name: <imagename>
ports:
- containerPort: 80
- containerPort: 443
restartPolicy: Always
The nginx file
The Dockerfile
Here is the file path of the actual proxy (static content in kiwoon-pages)
Here is the static content
Is there anything that looks glaringly wrong here? Let me know, thanks!
Since #tymur999 has already solved this issue, I decided to provide a Community Wiki answer just for better visibility to other community members.
It's important to know that browsers use the MIME type, to choose a suitable displaying method.
Therefore, the web server must send the correct MIME type in the response's Content-Type header.
In the MIME types documentation, we can find an important note:
Important: Browsers use the MIME type, not the file extension, to determine how to process a URL, so it's important that web servers send the correct MIME type in the response's Content-Type header. If this is not correctly configured, browsers are likely to misinterpret the contents of files and sites will not work correctly, and downloaded files may be mishandled.
In nginx, we can use the types directive to map file name extensions to MIME types of responses (see: NGINX documentation):
Syntax: types { ... }
Default:
types {
text/html html;
image/gif gif;
image/jpeg jpg;
}
Context: http, server, location
NOTE: A sufficiently full mapping table is distributed with nginx in the mime.types file.
As an example, suppose I have a simple website - a single HTML (index.html) and CSS (mystyle.css) file.
$ ls /var/www/html/
index.html mystyle.css
$ cat /var/www/html/index.html
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<link rel="stylesheet" href="mystyle.css"/>
<p>This is a paragraph.</p>
</body>
</html>
$ cat /var/www/html/mystyle.css
body {
background-color: aquamarine;
}
Without the correct MIME type for CSS, my website doesn't work as expected:
NOTE: The text/css MIME type is commented out.
$ grep -Ri -A 3 "types {" /etc/nginx/nginx.conf
types {
text/html html htm shtml;
# text/css css;
}
When the text/css MIME type is properly included, everything works as expected:
grep -Ri -A 3 "types {" /etc/nginx/nginx.conf
types {
text/html html htm shtml;
text/css css;
}
I am hosting a web application inside a Kubernetes 1.13 cluster behind an NGINX ingress controller. The Ingress specifies path: /my-webapp/?(.*) and annotations:
{ nginx.ingress.kubernetes.io/rewrite-target: /$1 } such that the webapp can be reached from outside the cluster at http://my-cluster/my-webapp. (The ingress controller is exposed as my-cluster.)
One remaining problem is that the webapp contains "relative" URLs that refer e.g. to CGI scripts and to CSS stylesheets. For instance, the stylesheet in <link rel="stylesheet" type="text/css" href="/my-stylesheet.css" /> currently does not load. I assume this is because the browser requests it at the wrong URL (http://my-cluster/my-webapp/my-stylesheet.css would be right) and that some more annotations are needed.
What is the correct configuration is such a case?
UPDATE The inspector reveals that the browser currently requests the stylesheet from URL http://my-cluster/my-stylesheet.css, which is indeed wrong and needs to be fixed.
UPDATE This looks like a related problem with an NGINX reverse proxy in general, not a Kubernetes NGINX ingress controller in particular. I wonder if and how the suggested recipes can also serve in this particular case. For a start, I have tried switching to a relative URL for referencing the stylesheet (per recipe One in the accepted answer), but this also has not worked so far:
<link rel="stylesheet" type="text/css" href="my-stylesheet.css" />, the browser apparently still tries to get the stylesheet from http://my-cluster/my-stylesheet.css, although it displays http://my-cluster/my-webapp in the URL bar and the inspector reports the same URL as baseURI.
Now this combination of annotations seems to do the trick:
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
proxy_set_header Accept-Encoding "";
sub_filter '<head>' '<head> <base href="/my-webapp/">';
nginx.ingress.kubernetes.io/rewrite-target: /$1
nginx.ingress.kubernetes.io/use-regex: "true"
I am currently using this version of the ingress controller:
-------------------------------------------------------------------------------
NGINX Ingress controller
Release: 0.23.0
Build: git-be1329b22
Repository: https://github.com/kubernetes/ingress-nginx
-------------------------------------------------------------------------------
In my situation, I must replace URL-s from wsdl service page and this my solution code that was written thanks to the above code
nginx.ingress.kubernetes.io/configuration-snippet: |
sub_filter 'http://example.com:80/project/domain/' 'http://example.com:80${PUBLISH_PATH}/project/domain/';
sub_filter_once off;
sub_filter_types text/xml;
${PUBLISH_PATH} - is the kuber domain specific
We started implementing PWA, As part of the implementation, I am importing manifest.json from the amazon s3 bucket. Getting following error.
Failed to load https://abcdefghij.com/static/pwa/Manifest.json:No 'Access-Control-Allow-Origin' header is present on the requested
I had written following code in index.html file
<link rel="manifest" crossorigin="anonymous" href="https://abcdefghij.com/static/pwa/Manifest.json"/>
will be thankful, if someone helps.
Does your https://abcdefghij.com/ server support cross-origin request?
For more information: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
I would not recommend disabling CORS.But you can white list Few sources using S3 buckets. CORS Has to be set on server side you can use this as a reference assuming you are using Node
For S3 use this
I managed to set up artifactory using our existing tomcat. I have set to ARTIFACTORY_HOME=/opt/artifactory, that part works well. There is, however, also the jfrog access.war file, which needs to be running as well. I didn't figure out which variable to use to specify its home, therefore it defaults to ~/.jfrog_access, which is not at all what I like.
I moved the content over to my $ARTIFACTORY_HOME/access and symlinked it, but that's not the way to go for sure. Any help appreciated.
In case someone is stumbling over this thread and struggles with the same problem:
Solution for me was to also extract the Context files (access.xml and artifactory.xml which are available in the zip file under <zip extract>/misc/tomcat) to the Tomcat configuration folder, e.g. $CATALINA_HOME/conf/Catalina/localhost/. After that the $ARTIFACTORY_HOME env will be recognized on Access startup.
A previous answer finally put me on the right track for solving this problem on Amazon Linux.
In addition to copying access.xml and artifactory.xml to ${catalina.home}/host/MY_HOSTNAME, I found that some other changes were needed.
I modified the docBase attributes in the XML context files because my server has multiple hostnames:
/usr/share/tomcat8/conf/Catalina/repo.mydomain.org/access.xml
<Context path="/access" docBase="${catalina.home}/host/repo.mydomain.org/access.war">
<Parameter name="jfrog.access.bundled" value="true" override="true"/>
<!-- enable annotations scanning of access jar files -->
<JarScanner scanClassPath="false">
<JarScanFilter defaultPluggabilityScan="false" pluggabilityScan="access*" defaultTldScan="false"/>
</JarScanner>
</Context>
/usr/share/tomcat8/conf/Catalina/repo.mydomain.org/artifactory.xml
<Context crossContext="true" path="/artifactory" docBase="${catalina.home}/host/repo.mydomain.org/artifactory.war">
</Context>
Important Note: In order to prevent the above two XML files from being deleted by Tomcat Manager during upgrades via Undeploy/Deploy WAR, make sure they are owned by root and not writable by the tomcat user:
chown root.root access.xml artifactory.xml
chmod 644 access.xml artifactory.xml
If you forget to do the above, you will likely end up missing these files, which will break the communication between the access and artifactory web applications, resulting in login failures ("Username or Password Are Incorrect"). In this case, these errors result from the lack of communication between the web applications, not a problem with the credentials themselves.
/usr/share/tomcat8/conf/Catalina/repo.mydomain.org/manager.xml
This gives me the ability to upload new versions of access.war and artifactory.war via https://repo.mydomain.org:8443/manager/html:
<Context docBase="${catalina.home}/webapps/manager" privileged="true" antiResourceLocking="false">
</Context>
Additionally, I created the following folder to serve as the artifactory.home:
sudo mkdir /usr/share/artifactory
sudo chown tomcat.tomcat /usr/share/artifactory
tomcat8.conf
Add (or modify) the following line:
JAVA_OPTS="-Dartifactory.home=/usr/share/artifactory -Djfrog.access.home=/usr/share/artifactory/access -Dartifactory.access.client.serverUrl.override=http://localhost:8080/access"
Note: The Access Client URL specified above must use localhost in order to avoid the Server HTTP parameter from being overwritten by Apache and its modules. For instance, if I use:
https://repo.mydomain.org/access/api/v1/system/ping
The Server HTTP header value in the response is:
Server: Apache/2.4.33 (Amazon) OpenSSL/1.0.2k-fips mod_jk/1.2.43
And the Access Client produces the following exception:
[ERROR] (o.j.a.c.AccessClientImpl:154) - Access client/server version mismatch. Client version: 4.1.5, Server version: 2.4.33 (Amazon) OpenSSL
Which means the Access Client is depending on the first string matching #.#.# in the server header. This seems like a really fragile part of the Access Client. They should have used X-JFrog-Access-Server or something instead of trying to control a value that is set by the web server. So, to reiterate, use http://localhost:8080/access to connect directly to the tomcat server.
Artifactory 6.2.0 depends on Apache Derby (the specific version can be found in jfrog-artifactory-oss-6.2.0.zip\artifactory-oss-6.2.0\tomcat\lib). This should be added as a shared library to Tomcat:
mkdir /usr/share/tomcat8/shared
cd /usr/share/tomcat8/shared
wget http://central.maven.org/maven2/org/apache/derby/derby/10.11.1.1/derby-10.11.1.1.jar
Add or modify the following line in catalina.properties:
shared.loader=${catalina.home}/shared/*.jar
Since we want https://repo.mydomain.org to go to the Artifactory webapp:
mkdir /usr/share/tomcat8/host/repo.mydomain.org/ROOT
echo '<html><head><meta http-equiv="refresh" content="0;URL=/artifactory"></meta></head><body></body></html>' > /usr/share/tomcat8/host/repo.mydomain.org/ROOT/index.html
And make sure the services automatically start on reboot:
sudo chkconfig httpd on
sudo chkconfig tomcat8 on
Artifactory will then be available at the url:
https://repo.mydomain.org/artifactory/webapp/
The problem is just happening on localhost, when I upload the application to AppEngine, It succesfully finds the css files.
I'm using python 2.7, the app is done on webapp2 and I'm using a local copy of bootstrap.
<link href="/static/bootstrap/css/bootstrap.css" rel="stylesheet" media="screen">
<link href="/static/bootstrap/css/bootstrap-responsive.css" rel="stylesheet">
Those are my links to the css files, they work when I deploy the app http://main-cocoa-597.appspot.com/cenira, but they don't on localhost.
app.yaml
application: main-cocoa-597
version: 1
runtime: python27
api_version: 1
threadsafe: yes
handlers:
- url: /favicon\.ico
static_files: favicon.ico
upload: favicon\.ico
- url: /static
static_dir: static
- url: /cenira.*
script: cenira.app
- url: .*
script: main.app
libraries:
- name: webapp2
version: "2.5.2"
- name: jinja2
version: latest
I think the problem has nothing to do with the app, since even the launcher's SDK Console is not loading It's css files either.
I just installed Windows, maybe there's something missing? How can I solve this?
EDIT:
just with a basic html (a div with a class), and linking to an external css file:
<link href="/css/asd.css" rel="stylesheet">
getting this:
GET file:///C:/css/asd.css net::ERR_FILE_NOT_FOUND
For PIL, add this to the libraries section of app.yaml:
- name: PIL
version: latest
To diagnose the 500 error in your css request, try adding this:
- url: /static/css
static_dir: static/css
mime_type = "text/css"
(This needs to be ABOVE your - url /static call, so it runs first