I registered my own URL scheme.
https://msdn.microsoft.com/en-us/library/aa767914.aspx
how do I create my own URL protocol? (e.g. so://...)
Link example: oce://10000
IE, firefox, windows explorer handle it fine. Id 10000 is opened correctly in my app.
Is it possible make this links clickable in Skype?
I already find this unanswered support ticket http://community.skype.com/t5/Windows-archive/Custom-URI-scheme-handlers/td-p/3627869
You can build a redirect page as suggested here: http://www.developerstalk.net/building-a-redirect-page.aspx
Maybe the easiest way to do this is simple redirect.
Use .htaccess and 301 redirect to desired location. That's the most easiest way. Then just let the server deal with everything.
Ideally, an application need to launch/execute URIs it doesn't support or recognize with the OS shell. Skype may be ignoring custom URIs as a security precaution. They don't want to launch unknown applications.
Related
The URL for app-maker is always pretty complicated and is not human readable...
Is there a way to configure a host name or simplify the URL, in order to have the users being able to remember it?
for example:
myapp.mydomain.com
or at least:
scripts.google.com/myapp_prod or similar?
Until now I wasn't able to find out a way to have a fixed URL for the prod deployment for example.
If you want that for accessing purposes only and if you have some kind of hosting, a permanent redirect will do the trick. Alternatively, you can use some javascript to redirect to the app url whenever the home page is loaded.
window.open(appurl, "_top");
But other than that, the comment provided by Markus Malessa is the most correct one.
I have deployed an ASP.NET website on IIS 7. I was able to access my site using the URL http://**local host**/sitename.aspx and all the formatting of my pages is looking good.
But when I access the same page by using the URL http://**servername**/sitename.aspx from another system or on the same server where I have been deployed, the page formatting is not working properly.
What would be the best solution for this? Thanks
First a fall to check your Js/Css file path where you have not mention static file path with localhost name.
For more detail go to browser and browse your url and press F+12 so development tool will be open and check there for broken url.
I am not sure why you are worrying about formatting soo much. I mean formatting should not affect you much unless you use <pre> in your html.
There are ways to modify the HTTP Response Using Filters. Can you please makesure none of these filters present in your application for release mode.
Generally i use HTTP compression feature of IIS to compress my content, but in browser it looks correct to me.
I have enabled HTTPS for my site. Some of the resources such as css and js files on my pages come from another domain which is on HTTP. Now the problem is when I visit the page, browsers display an alert message. IE says "Do you want to view only the page content that was delivered securely" and FF says "You have requested an encrypted page that contains some unencrypted information. Information that you see or enter on this page could easily be read by a third party."
I tried the technique mentioned by Paul Irish which is not working.
Any idea how I can resolve this issue?
I use asp.net 3.5 for my site.
The assumption he makes in the referenced article I think you missed is
… assuming the site you're pointing to has this asset available on
both HTTP and HTTPS.
Those resources need to be served over HTTPS as well, or you will always get that message. I don't believe there is a way around it, and there likely shouldn't be a way around it. You want everything running over HTTPS for a reason.
You need to serve those resources over HTTPS.
The Firefox Mixed Content Blocking Announcement does a good job explaining the security risks.
If you own/control the other website where the resource files are located, a good solution might be to move the resource files over to the website where both HTTP and HTTPS are supported, and change both websites to point to those files at their new location.
The situation is the following: I created a site with Plone, developed, used, but behind a test URL. Now it has to be published, but the test URL is not appropriate and I don't want to move the site. I think, if I use a redirect, it won't be appear in the URL-bar, only in the case of site start page. Am I wrong? (The test URL should not be used, because it will be a "semi-official" site.) What do you suggest to do?
As far as I can see Plone uses absolute URLs everywhere. I can add relative URLs, but if I create a new page, a new event, etc., then they have absolute URLs on other automatically generated inner pages. Is there any way to convert these URLs to relative paths? Is there any setting possibilty where only a checkbox changes this default setting?
Plone does not store your URLs in the database. It uses the inbound host header (and any virtual hosting configuration set up with rewrite rules in Apache or Nginx) to calculate the correct absolute URL when rendering the page.
In other words - as soon as you actually point the relevant domain name to the server with your Plone instance, it'll just work.
P.S.
You should put a bit more effort into asking your question. This is just a copy and paste of a half-finished email chain where you tried to get the answer from me in private. It's not very easy to understand what you're asking.
I think what you are looking for is url rewriting to handle virtual hosting. ie to get your site to appear as if it's the root url of a domain.
This is normally done via the webserver that normally sits in front of plone. For apache, here is a howto
http://plone.org/documentation/kb/plone-apache/virtualhost
for other servers
http://plone.org/documentation/manual/plone-community-developer-documentation/hosting
You can also achieve this directly in zope (via ZMI) using something called the Virtual Host
Monster. see http://docs.zope.org/zope2/zope2book/VirtualHosting.html
PS. I don't think your question is badly worded. Plone does serve pages with a "base" tag and what appears to be absolute urls. They aren't baked into the database but it's also not obvious that the solution to getting the url you want is the VHM url syntax and a proxying frontend webserver. There is a reason why it doesn't use relative urls... which I can't remember it was so long ago.
Dave Ward says,
It’s not exactly light reading, but section 4.2 of RFC 3986 provides for fully qualified URLs that omit protocol (the HTTP or HTTPS) altogether. When a URL’s protocol is omitted, the browser uses the underlying document’s protocol instead.
Put simply, these “protocol-less” URLs allow a reference like this to work in every browser you’ll try it in:
//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js
It looks strange at first, but this “protocol-less” URL is the best way to reference third party content that’s available via both HTTP and HTTPS.
This would certainly solve a bunch of mixed-content errors we're seeing on HTTP pages -- assuming that our assets are available via both HTTP and HTTPS.
Is this completely cross-browser compatible? Are there any other caveats?
I tested it thoroughly before publishing. Of all the browsers available to test against on Browsershots, I could only find one that did not handle the protocol relative URL correctly: an obscure *nix browser called Dillo.
There are two drawbacks I've received feedback about:
Protocol-less URLs may not work as expected when you "open" a local file in your browser, because the page's base protocol will be file:///. Especially when you're using the protocol-less URL for an external resource like a CDN-hosted asset. Using a local web server like Apache or IIS to test against http://localhost addresses works fine though.
Apparently there's at least one iPhone feed reader app that does not handle the protocol-less URLs correctly. I'm not aware of which one has the problem or how popular it is. For hosting a JavaScript file, that's not a big problem since RSS readers typically ignore JavaScript content anyway. However, it could be an issue if you're using these URLs for media like images inside content that needs to be syndicated via RSS (though, this single reader app on a single platform probably accounts for a very marginal number of readers).
The question of whether one could change all their links to be protocol-relative may be moot, considering the question of whether one should do so. According to Paul Irish:
2014.12.17: Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the
asset you need is available on SSL, then always use the https://
asset.
If you use protocol-less URLs to load stylesheets, IE 7 & 8 will download them twice:
http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/
So, this is to be avoided for CSS if you like good performance.
Yes, network-path references were already specified in RFC 1808 and should work with all browsers.
Is this completely cross-browser compatible? Are there any other caveats?
Just to throw this in the mix, if you are developing on a local server, it might not work. You need to specify a scheme, otherwise the browser may assume that src="//cdn.example.com/js_file.js" is src="file://cdn.example.com/js_file.js", which will break since you're not hosting this resource locally.
Microsoft Internet Explorer seem to be particularly sensitive to this, see this question: Not able to load jQuery in Internet Explorer on localhost (WAMP)
You would probably always try to find a solution that works on all your environments with the least amount of modifications needed.
The solution used by HTML5Boilerplate is to have a fallback when the resource is not loaded correctly, but that only works if you incorporate a check:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>
I posted this answer here as well.
UPDATE: HTML5Boilerplate now uses <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"> after deciding to deprecate protocol relative URLs, see here.
If you would like to make sure all requests are upgraded to secure protocol then there is simple option to use Content Security Policy header upgrade-insecure-requests
Content-Security-Policy: upgrade-insecure-requests;
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests
I have not had these issues when using ://example.com - but you do need to add the colon at the beginning. Yoast had a good write up about this a while back. But it's lost in his pile of blog posts.