What Is That Options Request Before Post And Cross Origin Resource Sharing

I was working on project that was sending a POST request with some data from a web client to a service hosted on a different domain. The service’s logs were saying no support for OPTIONS request, which made sence because it expects a POST request and that’s what it supports. So who is sending this OPTIONS request when I’m tring to sending a POST from my browser client? I checked the network tab in browser inspector, browser indeed was sending an OPTIONS request, that too with an empty body and I didn’t see any POST request. Weird!

If you have ever wrote any ajax call, there are high chances you would have encountered problems related to cross-domain, saying you’re not allowed to access resources that doesn’t have same origin. This happens when you try to call services from different hosts other than your own server through Javascript. And I knew the reason is browser’s Same Origin policy and what that is, what I didn’t knew was how it exactly works?!

What is Same Origin policy, well, the moment you navigate to an URL, your browser allows the website developer to execute theirs JavaScript on your machine. To limit what that script can do, like accessing data from another web page opened in another tab or cookies created by another websites, browser uses this Same Origin policy, which allow one domain to access resources that belongs to that domain only i.e. resources with same origin. This applies only on what already loaded JS can access through DOM or by making a Ajax calls and not on web page itself embedding static content e.g. images, CSS or Javascipt files itself.

When Javascipt of some website tries to access resources from other sites i.e. make a cross-origin request, the browser adds a Origin header with the request and checks the response header for specific headers like Access-Control-Allow-Origin which signals browser that server allows current origin to access its data. This happens if request does not modify data e.g. GET or HEAD request. For requests that modify data like requests with POST method or content type as application/json, browser first asks the other host if it allows requesting host to access their resource. If other host says yes, it goes ahead with your request.

Browser implements this by first sending something called a preflight request which is a HTTP request with OPTIONS method, containing a header Origin and other Access-Control-* headers describing original request’s method and content type, which server can respond with proper headers describing methods it supports for request from this origin and header it needs. Browser can cache this information and might not verify every time.

You can see this in browser’s Developer Tools. Open Inspect window for current or any web page other than example.com and execute following JS in console:

fetch("https://example.com").then(res => console.log(res))

You should seen error saying Cross-Origin Request Blocked and if you check Network tab, browser did made a GET request as specified above along with a Origin header but since the response header did not have any Access-Control-* headers, browser will not return the response to the client and hence you only saw error in console. Now try executing this JS:

fetch("https://example.com", {
  method: 'POST',
  body: JSON.stringify({"foo": "bar"}),
    'Content-Type': 'application/json'
}).then(res => console.log(res));

You’ll get same error in console and if you check Network tab again, you should see a OPTIONS request and not a POST request. Because the response of OPTIONS request does not have headers that say –allow current webpage to access it’s data, browser never sent the real request.

The OPTIONS request I was getting was this preflight request and since I was not handling this request, I never received the POST request which browser would have sent after receiving response from it’s first request. Handling this is what is called CORS i.e. Cross Origin Resource Sharing. From client side, this is relaxation to Same Origin Policy provided by browser. From server side, most of the API frameworks provides a library to handle this. You can specify which origin domain you want to allow and these libraries will handle the OPTIONS request for you and will respond with proper headers set.

This is good resource to read more about CORS.

When Your Sudo And Pacman Breaks

I needed to install Mongodb for a project I was working on, as usual I did:

$ sudo pacman -S mongodb

Now starting the mongodb.service with systemctl was failing without any specific error logs:

$ journalctl -u mongodb.service -b
-- Logs begin at Thu 2017-06-01 13:13:02 IST, end at Sun 2018-01-07 12:14:08 IST. --
Jan 07 12:05:56 TheBlackPearl systemd[1]: Started High-performance, schema-free document-oriented da
Jan 07 12:05:56 TheBlackPearl systemd[1]: mongodb.service: Main process exited, code=exited, status=
Jan 07 12:05:56 TheBlackPearl systemd[1]: mongodb.service: Unit entered failed state.
Jan 07 12:05:56 TheBlackPearl systemd[1]: mongodb.service: Failed with result 'exit-code'.
Jan 07 12:09:46 TheBlackPearl systemd[1]: Started High-performance, schema-free document-oriented da
Jan 07 12:09:46 TheBlackPearl systemd[1]: mongodb.service: Main process exited, code=exited, status=
Jan 07 12:09:46 TheBlackPearl systemd[1]: mongodb.service: Unit entered failed state.
Jan 07 12:09:46 TheBlackPearl systemd[1]: mongodb.service: Failed with result 'exit-code'.
lines 1-9/9 (END)

And running mongo and mongodb was throwing following error:

mongo: error while loading shared libraries: libboost_program_options.so.1.65.1: cannot open shared object file: No such file or directory

I seached this a bit and then installed boost package.

$ sudo pacman -S boost

And now running mongo was throwing different error:

mongo: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

I tries installing mongo-tools package which also installed openssl-1.0 along with it. And running mongo was still throwing same error. So I installed openssl which got me openssl-1.1. That’s where almost everything broke. Running sudo:

$ sudo pacman
sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"
sudo: unable to load /usr/lib/sudo/sudoers.so: libssl.so.1.0.0: cannot open shared object file: No such file or directory
sudo: fatal error, unable to load plugins

Since sudo was not an option now, I switched to root by su only to realize that even pacman is broken:

$ pacman -Ss openssl
pacman: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

Now, this was scary. How do fix broken packages without my package manager?

Searching for this I found grism’s answer to similar problem. Turns out current version of sudo and pacman depends on openssl-1.0 and I upgraded it to 1.1. To downgrade it, I didn’t need to download the 1.0 version package from web as installing mongodb-tools also installed openssl-1.0, pkg.tar.xz of which can be found at /var/cache/pacman/pkg. As per the above link, I extracted it in /tmp and made a symlink for libssl-1.0.0 and libcrypto-1.0.0 at /var/lib/:

# cd /tmp && tar xf /var/cache/pacman/pkg/openssl-1.0-1.0.2.n-1-x86_64.pkg.tar.xz
# ln -s /tmp/usr/lib/libcrypto.so.1.0.0 /usr/lib/libcrypto.so.1.0.0
# ln -s /tmp/usr/lib/libssl.so.1.0.0 /usr/lib/libssl.so.1.0.0

That is some terrible advice here, as symlinking one version to another can break mulitple things, but other solutions were suggesting to reinstall OS. Now, Arch Linux comes with absolute minimum built in packages which means reinstalling it would require reinstalling all the packages which I had installed over the span of 2-3 years since I’m using Arch. So obiously, I took the above advice and well that fixed my pacman. So first thing first, I need my sudo back, so I installed openssl-1.0 from downloaded .pkg.tar.xz:

# pacman -U /var/cache/pacman/pkg/openssl-1.0-1.0.2.n-1-x86_64.pkg.tar.xz

Exit root and try:

$ sudo ls
[sudo] password for nks:

That’s better. Back to MongoDB problem.

Lesson learnt – when they say upgrading a single package in Arch Linux in not recommended, they mean it. Infact they mean, never ever do that, instead do a full system upgrade like

$ sudo pacman -Syu



In “Corporate World” there is a lot of focus on documenting things, which I didn’t used to do much in college. And doing it made me realize it’s importance. While working on any project, now I’m in a habit of writing things down, what worked, what didn’t, everything, which most of the time involve troubleshooting.

And looking back last 2-3 year, I’ve spent countless hours on installing and fixing things, sometimes even on repeated stuff and other than StackOverflow, blogs of other people helped me more than anything. Because of these reasons I’ve started to write about breaking and fixing things publicly. Here is the list of the posts on same: