I'm brand new to SSL certificates, but I've just installed one on my site.
I link to my CSS, JS, Images etc like so:
<link rel="stylesheet" href="css/style.css">
However it is now blocked as coming from an unsecure location.
If I change it to this, it works:
<link rel="stylesheet" href="https://...com/css/style.css">
Is there a way to force "css/style.css" to be secure? Or do I have to rewrite some portions of my code?
Any help appreciated thanks
You don't need to use an absolute URL, as the two previous answers (wrongly) suggest. If you called the main page via HTTPS, then a relative URL such as css/style.css is resolved to an absolute HTTPS URL automatically. Why this doesn't work in your case, is impossible to say without seeing a live example.
Are you by any chance using the base element inside your HTML? If that is set to an HTTP URL, then that would of course screw up the automatic resolving of relative URLs to HTTPS.
Turns out you did have a base element, and it was the culprit.
Related
I'd like to scrape all the linked javascript and css files on a give domain with Scrapy. The issue is that I don't quite understand how to extract the links from the link elements.
Assume I'm scraping example.com. There are links to js and css of the form:
<link rel="stylesheet" href="/path_to_css/example.css"/>
<script src="/path_to_js/example.js"></script>
These links start from the root domain, so no problem. But if the links are like the ones below, it starts to get confusing:
<link rel="stylesheet" href="path_to_css/example.css"/>
<script src="path_to_js/example.js"></script>
These relative URLs are supposed to work such that if I'm on example.com/some_page/ the link paths are appended to that like: example.com/some_page/path_to_js/example.js. That's not how it always works in actual web pages however. On some web sites with language selection eg.example.com/en/some_page, the relative paths start from example.com/en instead of the full path of that page.
So, while expecting to find the files at example.com/en/some_page/path_to_js/example.js, you find them at example.com/en/path_to_js/example.js
Is there any way to understand from where the relative paths start from?
While scraping, Scrapy allows you to create an absolute URL from a Relative URL
You could do something like this
for link in response.css("link"):
response.urljoin(link.css("::attr(href)").extract_first())
for script in response.css("script"):
response.urljoin(script.css("::attr(src)").extract_first())
I am using ibm websphere and creating a Dynamic web project. All of my JSP files are in my WEB-INF folder and i use servlet mapping in my web.xml file to make them accessible. This has worked fine so far. however i have problem with my CSS. as always, my CSS file is located in WebContent in a folder named css. heres my link for my jsp
<link rel="stylesheet" href = "css/styles.css">
I'm having no luck getting my css to show...
what am i missing?
The relative URLs in the generated HTML output are by the browser interpreted relative to the request URL (as you see in browser's address bar), not to their physical location in the server's disk file system. It's namely the webbrowser who has got to download them by a HTTP request, it's not the webserver who has got to include them from disk somehow.
One of the ways is to use a domain-relative path for those resources, i.e. start with /. You can use ${pageContext.request.contextPath} to dynamically inline the current webapp's context path.
<link rel="stylesheet" href="${pageContext.request.contextPath}/css/styles.css">
This will end up in the generated HTML output as follows:
<link rel="stylesheet" href="/yourContextPath/css/styles.css">
This way the browser will be able to download them properly.
See also:
Browser can't access/find relative resources like CSS, images and links when calling a Servlet which forwards to a JSP
I think you need to see it from the browser's perspective, how it is the URL of the page, the context path and the current path.
If your app context path is for example "myApp" then you can do something like this to make it work:
<link rel="stylesheet" href = "/myApp/css/styles.css">
If you want to make it relative so it does not depend on the context path, then if your url looks like http://localhost:8080/myApp/myservlet/file.jsp
Then your link tag would be
<link rel="stylesheet" href = "../css/styles.css">
Firebug or the chrome console may be really helpful to understand what the browser is trying to fetch.
Hope this helps!
I serve content from a subdirectory on my web server, for example:
http://www.myserver.com/subtree
I notice that the CSS is not rendering correctly, so I look at the source of the HTML file:
<link rel="stylesheet" type="text/css" href="static/stylesheets/style.css"/>
One would expect that browsers such as Chrome or Firefox attempt to find this css at
http://www.myserver.com/subtree/static/stylesheets/style.css
When hovering over the link, I can see that it links me to
http://www.myserver.com/static/stylesheets/style.css
It may be useful to note that I'm using apache's mod_proxy to serve the content from /subtree from another server running on the local machine. However, my reasoning is that the browser doesn't know about this and it looks like the content is coming from myserver.com/subtree so therefore it should look for the resources using the relative path.
What am I missing?
That's to be expected. The browser cannot know that /subtree is a folder (instead, it could also be just a file served as text/html). If you want the browser to include this path fragment in relative path lookups, make sure that it ends with as slash, as in:
http://www.myserver.com/subtree/
If you are using Apache, you can use mod_dir's DirectorySlash directive to automatically fix this for you: mod_dir documentation
I hope this help:
Browsers when see URLs which start with /, they remove the path part of the document.location.href, or get the value of document.location.origin and append the current URL to the end of it.
When they see URLs which don't start with '/', they append the current URL to the end of document.location.pathname.
From a comment by Sam Dufel on the question:
I've noticed that with friendly URLs,
browsers will often look in a
different relative path depending on
whether or not you include a trailing
slash. I.E,
http://www.myserver.com/subtree would
have a relative root of
http://www.myserver.com/, and
http://www.myserver.com/subtree/ would
have a relative root of
http://www.myserver.com/subtree/
(here so you can mark this question as answered)
Might be a silly question, just wanted to know do the following ways on including CSS have any impact on the server response time. If yes, which is the better method and how
Way 1 :
<link rel='stylesheet' href='css/some.css'/>
Way 2 :
<link rel='stylesheet' href='http://www.somesite.com/css/some.css'/>
No, your browser converts any URL into an absolute URL before making the request, so it won't make any difference.
Depends. If you want to have the same website to run in the dev, test as well as prod environments without changing code, you'd like to use relative paths. Instead of that you can also specify a <base> element so that you only need to specify the domain only once -if necessary dynamically using a server-side language.
Another thing to take into account when hardcoding the protocol (the http: part) is that you would like to use at least protocol-relative URL's when your website may switch between HTTP and HTTPS regulary. A CSS file which is hardcoded on http://example.com/style.css may cause security complaints in most webbrowsers about "unsafe content". In such case you'd like to use relative paths such as style.css or if you persist in using the full domain name, use //example.com/style.css instead. This by the way also applies on all other resources like Javascripts and (CSS) images.
Sorry if this is a stupid question...
I've developed an application that creates absolute links by prepending urls with the site root (of whichever site it is hosted).
For example:
<link rel="stylesheet" href="<?=SITE_ROOT?>/assets/css/global.css">
Notice that a slash is coming after site root. I need to convert this now to be relative links, so I tried using a dot as the value of SITE_ROOT.
This creates this:
<link rel="stylesheet" href="./assets/css/global.css">
As far as I can tell, it works fine. Is this a legitimate relative link? Or is there a reason why I shouldn't do it this way?
Note: I'm not trying to go up a directory, otherwise I would use ../ I'm simply trying to stay in the same directory. Since there is a slash after SITE_ROOT, I can't leave it blank or it would become a root relative link.
Update: Will this work with IIS?
These links work on the client, not on the server, and as far as I know should behave the same as <a> links. ./assets/css/global.css is the same as assets/css/global.css, meaning the folder assets under the current sub site. the ./ part is redundant.
If you what a link relative to the server you should start it with a slash, ie: /assets/css/global.css will go to stackoverflow.com/assets/css/global.css, even when you are on a sub site.
I think it's fine.
I think it's client side, so it should work with ASP.Net.
its legitimate.
Just check if this works with IIS server. IMO it should. It does with Apache.
jrh