Category: HTTP

How to Redirect HTTP to HTTPs Zimbra 8.8.*

Zimbra Supports HTTPs by Default:

By default Zimbra will use HTTPs support only and disable HTTP use on the webmail client. But users will always use non http port to access the webclient. Users do not like to type https before the domain each time to get into the webmail client. Zimbra uses Nginx to run the proxy services to access the Javamail Client of Zimbra. Zimbra supports 5 types of proxy services through Nginx:

  1. redirect
  2. both
  3. http
  4. https
  5. mixed

You may check the following for details:

Enabling_Zimbra_Proxy_and_memcached

How to Redirect HTTP to HTTPs automatically in Zimbra 8.8*

The most popular out of 5 options for proxy services, is to redirect. To do this, you can run the following:

zmprov ms `zmhostname` zimbraReverseProxyMailMode redirect

This will redirect your URLs to the zimbra hostname based HTTPs.

Now, restart the proxy services:

su - zimbra
zmproxyctl restart

Hope this helps.

Can You Cancel/Abort/Rollback a HTTP Request?

There are cases, where Frontend developers wants to cancel the REST Requests that they submit using Ajax. It is one of the popular question among the Frontend developers community. Let’s try to focus on this case today.

To answer the question in short, No, you can not cancel a HTTP Request once it is submitted. There are catches require shear understanding here. Let’s elaborate a bit.

HTTP is Stateless by Design

HTTP is stateless by design, so what happens when there is no state for a request? It means we do not know the destination, what is happening with that specific requests at the back, but only can acknowledge the response. For example, if you have a REST API behind a load balancer. If you put a POST request to the API, you will not know which server going to serve your requests out of many HTTP servers behind the load balancer. For such cases, we create ‘cookies’ or ‘sessions’ on our application end for our full fledged web applications and extend the functionality of HTTP, to store state of a request and following it. For each form request for example, we submit a state along with the app, to let load balancer understand the state and follow me to the destination. Isn’t it? But we have to remember, this is not a HTTP feature, this is done at application level to add statefullness in HTTP requests.

What does this mean? It means, as there is no state for REST, we are not aware of the destination here, but only the response. So how can we cancel a requests, whose actual destination we are not aware of? Now you might think that, how about adding a cookies and cancel it? Yes, we do that on web applications layer, but can REST HTTP Requests be stateful? Not really, that is not by design of HTTP or REST unfortunately.

So, Does That Mean We Can Never Cancel an API Call?

If you are using REST, then it means you can never cancel the API call. If it gets submitted, it will continue processing in the backend even if you stop it in the frontend. But if ‘Cancelling’ is much important for your application through the API call, then you must consider other alternatives, like SOAP or RPC. RPC is stateful API architecture, and it is possible to design a cancel request for this. Please note, RPC doesn’t implement ‘cancel’ by default, but as this is stateful, you are able to design a ‘cancel’ request with the RPC call. Google has a RPC called ‘gRPC’, which is a stateful API architecture. That means, it is possible for you to implement cancel/abort or event rollback/restore a state with gRPC.

A Google application called ‘Firestore’ database has support for gRPC which is basically a stateful version of stateless REST API of Firestore.