http://www.w3.org/Provider/Style/URI.html describes that "cool" URIs don't change and don't expose details about the technology.
http://www.w3.org/TR/cooluris/ provides further details when it comes to semantic web (RDF) URLs.
The question I have is: can https URLs ever be considered cooluris in this regard?
they expose the access technology (ssl)
the same resource is sometimes accessed by http (eg on intranet) and https (eg on extranet)
It seems to me the best way is NOT to use https to identify things in RDF, but only http. Many servers nowadays automatically redirect http to https for publicly accessible resources (especially if you have an account at that site).
What do you think?
I don't see why you couldn't use https URIs. First of all 'S' in https means secure and not SSL. Hence it doesn't expose technological details. As long as you stick to https forever, this shouldn't make a difference
However a 303 redirect is commonplace in the Semantic Web. It may be better use http URIs as identifiers and redirect. You could even redirect to a different document based on intranet (http) or extranet (https) if that's desired and keep the id stable.
Related
When sending data from a server / device through HTTP, to a destination that is enforced by https, is that data encrypted in transit?
HTTP -> HTTPS
Or does the source and the destination both have to enforce HTTPS?
A protocol is the language between a client and the server. This language might have features including ones related to security. HTTP is basically for browsers requesting web resources from web servers without any encryption, authentication or integrity protection. HTTPS is the same, but one that provides these features (HTTPS is actually HTTP, protected by TLS).
Each tcp connection between components uses one protocol (it's sometimes a little more difficult than that, but let's stick with this, it's good enough for now). In case of web components, it's typically either http or https. Each resource that is downloaded (a page, an image, a javascript file, any resource) is typically downloaded in its own separate connection. Whether that will be http or https depends on how the page references it.
So in practice, if you have a look at a html page that you downloaded over http, it can still reference resources with https urls, in which case those will be downloaded by your browser via https. It can also happen the other way round, a page downloaded over https can reference resources over plain http, but your browser will then warn you.
In short, your question doesn't make sense because you don't "send data through http, to a https destination". If the destination is https, the connection will be using https. In a web application, the page itself can be downloaded via http (in which case the html code and any data embedded in the html itself will not be protected against man-in-the-middle attackers), but it can reference further resources, images, css, javascripts via https, which your browser will then download securely.
I have one wordpress website, in that am getting lot of errors day by day. So I like to change my normal HTTP to HTTPS. So please can you explain it is very useful and secure for my website.
If your website does not have https in the web link this means that you do not have installed SSL. Most of the modern web browsers treat any website without SSL installed as insecure. This may be one of the reasons for your website's issues.
I found the following answers to the question of the difference between HTTP and HTTPS.
Difference between HTTP and HTTPS
To know about the reasons for using SSL follow the link given below:
Reasons for using SSL
10,000ft view...
http is an unencrypted protocol for sending and retrieving data from servers in a web browser (among other uses). https is the same protocol but wrapper in SSL, a security tool that encrypts communications between the browser and server. This is what what banks and other websites use to ensure your data (like financial info) is protected when sent to your browser and cannot be read by someone on the same network.
Checkout articles like this and google the topic for more info.
Hope this helps.
Is there any possibility to send HTTP headers on an ftp:// URL? How would I go about it?
What I want is HTTP based crawlers to see an HTML Response (in the headers) while human users see the pure FTP Content.
What would be the smartest way of solving this problem? I thought about user agent specific redirection, however this seems to be against most search engine's guidelines.
What I want is for bots to index an HTTP version of the content, while normal users can get access to the FTP version, all while using a single ftp:// URL.
Is this doable?
It's NOT doable.
You cannot redirect ftp:// URL to http:// URL. The FTP protocol has no redirects. FTP protocol does not even know what URL is. Nor does a web browser (acting as an FTP client) send "user agent" or anything similar to the FTP server.
There are also no headers in FTP protocol (but that's just a technicality, comparing to the fact above).
FTP protocol is completely different to HTTP.
You are obviously confused by the web browsers (all of them) presenting an FTP resource the same way as an HTTP resource. But it's just a "game" by the browsers. They are nowhere near similar.
Note that FTP was invented eons before Internet, HTTP, web and URLs.
Though note that you may be able to do it the other way around. You should be able to redirect HTTP to FTP.
But I still do not think it's a good idea. If the clients need FTP, they probably want to use a real FTP client, not a web browser. And a real FTP client won't understand HTTP (redirects).
But this question is kind of meaningless, now that all major web browsers are gradually removing a support for FTP anyway.
Wikipedia defines HTTP(S) or S-HTTP as a security layer over HTTP:
Technically, it is not a protocol in and of itself; rather, it is the
result of simply layering the Hypertext Transfer Protocol (HTTP) on
top of the SSL/TLS protocol, thus adding the security capabilities of
SSL/TLS to standard HTTP communications.
Logically, it implies that every feature and aspect of HTTP (e.g. methods and status codes) exists in HTTPS.
Should I expect any caveats or differences when switching an existing HTTP REST interface to HTTPS?
There doesn't seem to be any limitation of what you can do with HTTP but not HTTPS. The only limitations/differences relate to the fact that the connection is encrypted. As Eugene mentioned, this includes the fact that HTTPS cannot be proxy-cached. There are however some caveats:
HTTP inline content inside HTTPS page
If you start using HTTPS for sites where you originally used HTTP, problems might arise with HTTP inline content, e.g. if you use 3rd party HTTP services or cross-domain content:
scripts: google maps API
iframes: other webs, facebook, google ads, ...
images, static google maps, ...
In that case, many browsers will disable the "insecure" HTTP content inside HTTPS page! For the user, it is very hard to switch this off (especially in Firefox).
The only reliable way around that is to use protocol-relative URLs. So, instead of:
<script src="http://maps.googleapis.com/maps/api/js?v=3.exp&sensor=false"></script>
which would break on HTTPS page, you will just use
<script src="//maps.googleapis.com/maps/api/js?v=3.exp&sensor=false"></script>
which will work as HTTP on HTTP page and as HTTPS on HTTPS page. This fixes the problem.
The downside of course is that it is useless encryption of large amount of network traffic, that is not vulnerable and wouldn't normally have to be encrypted. This is the cost of the paranoid browser approach to security (like year ago, there was no warning from FF in this situation, and I was completely happy. World changes ...)
If you don't have signed SSL certificate for your domain
Another caveat of course is that if you don't have SSL certificate for your domain which is signed by trusted CA authority, then if your users will use HTTPS, they will have to pass a terrible scary 4-5 step procedure to accept the certificate. It is almost impossible and unprofessional to expose an average user (unaware of the problematics) to this. You will have to buy certificate in this case. Many times you end up using HTTP instead of HTTPS because of this. So if you cannot afford to buy the certificate, the browser paranoia forces you many times to use insecure HTTP protocol instead of HTTPS. Again, 6-7 years ago, it wasn't the case.
Mixing HTTP and HTTPS - cookie and authorization problems
If you use both HTTP and HTTPS within the same session, you might run into problems because sometimes they will be treated as separate sites (even if the rest of the URL is the same). This might be the case of cookies - in some cases they will not be shared between HTTP and HTTPS. Also, the HTTP authentication - RFC2617 will not be shared between HTTP and HTTPS. However, this type of authentication is now very rare on the Web, possibly due to lack of customization of the login form.
So, if you start using HTTPS, easiest way is then to use HTTPS only.
After several years of running HTTP over HTTPS, I am not aware of any other caveats.
Performance Considerations
HTTP vs HTTPS performance
HTTPS vs HTTP speed comparison
HTTPS Client/Broswer Caching
Top 7 Myths about HTTPS - Note commentary on HTTPS caching that is handled differently in browsers. It's from 2011 though, the browsers might have changed.
Will web browsers cache content over https
More on why there is no HTTPS proxy caching
Can a proxy server cache SSL GETs? If not, would response body encryption suffice?
UPGRADE command in Websockets via HTTPS
While the WebSocket protocol itself is unaware of proxy servers and firewalls, it features an HTTP-compatible handshake so that HTTP servers can share their default HTTP and HTTPS ports (80 and 443) with a WebSocket gateway or server. The WebSocket protocol defines a ws:// and wss:// prefix to indicate a WebSocket and a WebSocket Secure connection, respectively. Both schemes use an HTTP upgrade mechanism to upgrade to the WebSocket protocol.
http://en.wikipedia.org/wiki/WebSocket
As a coder of REST, I do not see any possible caveats when you switch HTTP REST to HTTPS. In times if you find some, you would definitely have them in normal HTTP REST too.
As far as I can work out, http://www.example.com is technically a subdomain of http://example.com.
Is it better to have www.example.com as a separate subdomain (pointing at the same content), or is it better to do a perminent redirect of all traffic from http://example.com to www.example.com (or visa versa)?
Excuse my ignorance, but the reason I ask is that I'm worried that having two locations online (one with the www, one without), could cause problems with SEO, cookies, analytics etc.
Thanks!
G
Yes, if it is the same content, then give it a single URI; and redirect example.com -> www.example.com not the other way around (www. is the convention and is where systems will most likely look first). If you host on both urls, then Spiders and other bots may be smart enough to realize that it is the same, but why rely on it when a simple redirect ensures they know?
This also means a slightly simple web server setup (only hosting a single domain) and will be easier down the road if you do things like enable ssl or load balancing.
The only (arguable) downside to redirects is that it will mean an additional http request if the user gets it wrong.