Angular Rxjs Error Handling flow

In Angular 2+, http are all RX based. so the error flow is quite different from what we used to have in angular 1.x’s promise based way.

consider the code

.map((res: Response) => {
return res.json();
.catch((err) => {
Observable.throw(‘my custom err msg’);
}, (err) => {
}, ()=> {

So the basic flow is if anything exception happened, the error handler function in the catch block will be called first. That function should return an Observable since it is a chain. Then the (err) function will be invoked. In the context of an HTTP request in Angular2, a response with a status code different than 2xx is considered as an error.

Note, if we do not use Observable.throw() in catch but return some random result, it would probably result in funky result. In the ​subscribeToResult function, there are multiple type checks. For example, if we return an array, if would be treated valid and be passed to the first handler rather than the error handler. If we return a random object like the error object, we will get TypeError: unknown type returned, error and trigger the 2nd handler(error handler).

Another note is if angular will return some odd error object with status: 0 when invoking some non-exist cross origin endpoints. This is because Whenever you make an api call to a non existing route, the browser sends a preflight request (a) . If the backends error handle strategy is to return an http response with 404 code and the error details in the body, the browser returns a generic error with http status code 0 without the actual server’s payload. The second call is never made because there is no sense in doing it since the preflight went wrong. In the end the error thrown have 0 status without any information about the real cause of the error.


Angular HttpPromise: difference between `success`/`error` methods and `then`’s arguments

According to AngularJS doc, calls to $http return the following:

Returns a promise object with the standard then method and two http specific methods:success and error. The then method takes two arguments a success and an error callback which will be called with a response object. The success and error methods take a single argument – a function that will be called when the request succeeds or fails respectively. The arguments passed into these functions are destructured representation of the response object passed into the then method.


The major difference between the 2 is that .then() call returns a promise (resolved with a value returned from a callback) while .success() is more traditional way of registering callbacks.

Promise-based callbacks (.then()) make it easy to chain promises (do a call, interpret results andthen do another call, interpret results, do yet another call etc.).

The .success() method is a streamlined, convenience method when you don’t need to chain call nor work with the promise API (for example, in routing).

In short:

  • .then() – full power of the promise API but slightly more verbose
  • .success() – doesn’t return a promise but offeres slightly more convienient syntax


How SSL works

Simple version

  1. Your web browser downloads the web server’s certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority.
  2. Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server’s certificate was indeed signed by the trusted certificate authority.
  3. The certificate contains the domain name and/or ip address of the web server. Your web browser confirms that the address listed in the certificate is the one to which it has an open connection.
  4. Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key.

Note that the certificate authority (CA) is essential to preventing man-in-the-middle attacks. However, even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic, since they have no way to gain access to your shared symmetric key.


SSL协议使用不对称加密技术实现会话双方之间信息的安全传递。可以实现信息传递的保密性、完整性,并且会话双方能鉴别对方身份。不同于常用的http协议,我们在与网站建立SSL安全连接时使用https协议,即采用https://ip:port/的方式来访问。当我们与一个网站建立https连接时,我们的浏览器与Web Server之间要经过一个握手的过程来完成身份鉴定与密钥交换,从而建立安全连接。具体过程如下:
客户端检查服务器证书,如果检查失败,提示不能建立SSL连接。如果成功,那么继续。客户端浏览器为本次会话生成pre-master secret,并将其用服务器公钥加密后发送给服务器。如果服务器要求鉴别客户身份,客户端还要再对另外一些数据签名后并将其与客户端证书一起发送给服务器。
如果服务器要求鉴别客户身份,则检查签署客户证书的CA是否可信。如果不在信任列表中,结束本次会话。如果检查通过,服务器用自己的私钥解密收到的pre-master secret,并用它通过某些算法生成本次会话的master secret。
客户端与服务器均使用此master secret生成本次会话的会话密钥(对称密钥)。在双方SSL握手结束后传递任何消息均使用此会话密钥。这样做的主要原因是对称加密比非对称加密的运算量低一个数量级以上,能够显著提高双方会话时的运算速度。


 Complete Version

To see a complete worked example of this process using Firefox connecting to,


cert = identity_info + public key + digit signature(CA signed identity-info)

my another post in Chinese about cert.

4 questions need to be address during the authentication:

  1. Has the Digital Certificate been issued/signed by a Trusted CA?
    in browser, already CA installed. In java, import others from `cacert` file
  2. Is the Certificate Expired – checks both the start and end dates
    make sure it is not expired
  3. Has the Certificate been revoked? (Could be OCSP or CRL check)
    either from a Certificate Revocation List (CRL), OR from a Online Certificate Status Protocol (OCSP).
  4. Has the client provided proof of possession?
    sign the message’s hash with its private key and send along with the cert so that the receiver could use the public key to decrypt the message hash and do a hash to the message and then compare.

Client certificate(2 way SSL)

Client also need cert from CA(same or another) as well as the private key. Server need the CA which signed the client cert in its cacert.

During the handshake, the client not only send the cert to the server, but also something signed by its private key. More specific: according to RFC5246 7.4.8.  Certificate Verify  in which client sign the handshake messages in the `Certificate Verify` message of the TLS handshake so that the server can verify it against the public key sent in the client certificate. Without this step, no client-certificate authentication would be taking place.

meta tag “HTTP=EQUIV”

By using the so called HTTP-EQUIV tag you are able to add certain values to your website. HTTP-EQUIV meta tags define the header of an HTML document. This is a section of code that is sent to your browser before the rest of the page. It communicates to your browser certain introductory information about the page. You can think of it as a “Hello, I am a HTML page. I was born on such-and-such a date and live on such-and-such a server. I was last modified on such-and-such a day, etc…

This introductory information is normally never seen by the end user.

Several variaties are possible:

<meta http-equiv="expires" content="date">

Example meta tag <meta http-equiv=”expires”

Add the following meta tag in the HTML source of your page:

<meta http-equiv="expires" content="mon, 27 sep 2015 14:30:00 GMT">

The date has to be added in the RFC850 format.

Example metatag <meta http-equiv=”pragma”

Another variant is:

<meta http-equiv="pragma" content="no-cache">
This tag make sure your page will not remain in the cache of the computer of your visitor. It’s useful if the content of the page regularly changes, e.g. if you have a newspage on your website.

Example meta tag <meta http-equiv=”window-target”

Another variant is the so called window target:

<meta http-equiv="window-target" content="_top">
This meta tag makes sure that others are not able to show your page in a frame on their own website.

Example meta tag <meta http-equiv=”Set-Cookie”

Another variant is the so called set cookie:

<meta http-equiv="Set-Cookie" content="ACCOUNT=9983373;
path=/; expires=Thursday, 20-May-07 00:15:00 GMT">

With this cookie-tag you are able to place cookies that are only temporary or have an expiration date.
( CONTENT=”name=data; path=path; expires=Day, DD-MMM-YY HH:MM:SS ZON”>)

Example meta tag <meta http-equiv=”pics-label”

Another variant is the so called picture label:

<meta http-equiv="pics-label" content="text">
This is a specific tag that provides you the possibility to add a value to the pictures on your website, e.g. “violence”, “erotic” or “for all ages”.
PICS = Platform for Internet Content Selection

Click here for more information about this standard

Example  meta tag <meta http-equiv=”refresh”

Another variant is the so called refresh value:

<meta http-equiv="refresh" content="value">
This refresh-tag will automatically redirects you to another webpage.

<meta http-equiv="refresh" content="30; ,URL=">

The number “30” is the number of seconds and pages/register.php is the page your customer will be redirected to.

Where do you add this http-equiv= tag?

You may add this http-equiv= tag to all of your webpages, so not only in the first index page. Make sure that on every page relevant meta tags are added.  Add keywords and phrases that are relevant and correspond to the text and the language on that specific page. It might be a lot of work to add specific meta tags to each page but you will notice in time that it works!

Using HTML To Prevent page from cached:

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />

The Cache-Control is per the HTTP 1.1 spec for clients (and implicitly required by some browsers next to Expires), the Pragma is per the HTTP 1.0 spec for clients and proxies and Expires is per the HTTP 1.1 spec for clients and proxies. Other Cache-Control parameters are irrelevant if the abovementioned three are specified. The Last-Modified header as included in most other answers here is only intersting if you actually want to cache the request, so you don’t need to specify it at all.

Note that when the page is served over HTTP and a header is present in both the HTTP response headers and the HTML meta tags, then the one specified in the response header will get precedence over the HTML meta tag. The HTML meta tag will only be used when the page is viewed from local disk file system. See also W3 HTML spec chapter 5.2.2. Take care with this when you don’t specify them programmatically, because the webserver can namely include some default values. To verify the one and other, you can see/debug them using Firebug Net panel.


Here is another detail Useful HTML Meta Tags

What happens when you type a web page address in the address bar

  1. Your browser, if it doesn’t already know, will ask your OS’s DNS system what the address (IP address) of the host (“,” for example) is. If your OS doesn’t know, it will query third-party DNS servers (those of your ISP, for example).
  2. Once an address is obtained, your web browser establishes a TCP/IP socket connection, typically on TCP port 80, with the web server at the IP address it resolved the host name to.
  3. Once your browser has established this connection, it sends an HTTP GET request to the web server for whatever resource was requested in your URL. For example, would mean you’d send a ‘/’ request to whatever web server is at
  4. The web server will then, typically, respond to the request with an HTTP response, typically containing HTML. Your web browser downloads this response.
  5. Your web browser renders the HTML. It may need to send additional requests for any scripts, stylesheets, images, or other resources linked to in the HTML.

Why is apache used in front of tomcat

  • Performance – If you have a lot of static content, serving it with Apache will improve your performance. If most of your content is dynamic, using Tomcat or Glassfish alone will be just as fast (probably faster).
  • Scalability – You can load balance multiple instances of your application behind Apache. This will allow you to handle more volume, and increase stability in the event one of your instances goes down.
  • Security – Apache, Tomcat, and Glassfish all support SSL, but if you decide to use Apache, most likely thats where you should configure it. If you want additional protection against attacks (DoS, XSS, SQL injection, etc.) you can install the mod_security web application firewall.
  • Additional Features – Apache has a bunch of nice modules available for URL rewriting, interfacing with other programming languages, authentication, and a ton of other stuff.

    Different view is  HERE:

    • The AJP connector does not and will not support advanced IO meaning no CometWebsockets, etc.
    • If your not using AJP I have noticed there is a pretty big proxy overhead when using mod_proxy for Apache. So if your looking for low latency Apache infront would not be good.
    • Apache has a rather big foot print compared to Nginx or Lighttpd etc.

    Putting Apache infront does NOT: