DEV Community: Dawit

How to Bypass Ad Blockers for Vercel Analytics in Nuxt

Dawit — Tue, 24 Jun 2025 16:50:41 +0000

The Problem: Analytics Blocked by Ad Blockers

Vercel Analytics offers a seamless & privacy-friendly way to track page views and performance for apps hosted on the platform. However, many ad blockers and VPN providers recognize and block requests to known analytics endpoints, such as /_vercel/insights/script.js, which could result in missing valuable data from users.

The Solution: Proxying Analytics with Nuxt Middleware

By proxying your analytics through a unique, project-specific endpoint rather than the default one, these blocklists can be avoided. Nuxt allows you to create custom endpoints directly within your application with its powerful server middleware feature powered by Nitro. You can use this feature to proxy Vercel Analytics requests through a unique path, effectively disguising them from most blockers.

Create a Proxy Middleware

First, set up a server middleware in your Nuxt project that intercepts requests to a custom path (e.g., /my-analytics/) and forwards them to the real Vercel Analytics endpoint.

Create a file at server/middleware/analytics-proxy.ts (Nuxt will auto-register it as a server middleware):

// server/middleware/analytics-proxy.ts
import { defineEventHandler, proxyRequest } from "h3";

export default defineEventHandler(async (event) => {
  // Only handle requests starting with your custom analytics path
  if (event.node.req.url?.startsWith("/my-analytics/")) {
    // Replace your custom prefix with the real Vercel Analytics endpoint
    if (event.node.req.url?.startsWith("/my-analytics/")) {
    const targetPath = event.node.req.url.replace(
      "/my-analytics",
      "/_vercel/insights"
    );

    return proxyRequest(event, `https://yourdomain.com${targetPath}`);
  }
});

This middleware listens for requests to /my-analytics/ and proxies them to the actual analytics endpoint.

Inject the Analytics Script

Next, update your app to load the analytics script from your new path. In your main layout or a Nuxt plugin, use the useHead composable:

// app.vue
useHead({
  script: [
    {
      src: "/my-analytics/script.js",
      async: true,
      "data-endpoint": "/my-analytics"
    }
  ]
});

This ensures your app loads the analytics script from the custom path, which is then transparently proxied to Vercel.

Since the script is loaded using useHead, the @vercel/analytics package is no longer needed.

Verify and Adjust

You can visit the network tab from your browser’s developer tools to confirm that requests to /my-analytics/script.js and related endpoints are not being blocked by ad blockers. If they are, you can try changing the custom path to something even less conspicuous.

That's it. Thanks for reading.

👨‍💻 Let's Connect › Bluesky · X · GitHub · LinkedIn

How to Register Custom Directives in Nuxt 3

Dawit — Mon, 11 Nov 2024 13:11:45 +0000

TL;DR

Create a plugin file in your plugins/ directory, which is where we'll have access to our Vue app instance.

We can define and register our custom directive there:

// ~/plugins/my-directives.ts
export default defineNuxtPlugin((nuxtApp) => {
    nuxtApp.vueApp.directive('highlight', {
        mounted(el, binding) {
            el.style.backgroundColor = binding.value
        }
    });

    // Register more directives as needed
});

In Detail

In Vue, directives are special attributes on HTML elements that are used to extend and manipulate their behavior. Vue provides several built-in directives:

v-bind - used to dynamically bind an attribute to a JavaScript expression,
v-on - used to attach event listeners to elements,
v-if/v-else-if/v-else - used to conditionally render elements,
and so much more.

For more specific and advanced use cases, Vue provides a way to create custom directives. These can be particularly useful for lower-level DOM manipulations.

In a plain Vue app, to register custom directives at the app level, we can attach it to our app instance as such:

const app = creatApp({});

app.directive('highlight', {
    mounted(el, binding) {
        el.style.backgroundColor = binding.value
    }
});

We can then use the directive on any element globally within our app:

<p v-highlight="'yellow'">This text will be highlighted!</p>

How about in Nuxt?

To achieve the same functionality in Nuxt, we will need access to our Vue app instance, and we can use a plugin to do so.

Plugins in Nuxt can be used to add functionality to an application at the Vue app level. They get loaded and executed when the Vue app is created, and files inside the plugins/ directory of a Nuxt app are automatically registered as plugins by Nuxt.

In Nuxt, we can create a plugin file in the plugins/ directory, which we can use to globally define and register our custom directives:

// ~/plugins/my-directives.ts
export default defineNuxtPlugin((nuxtApp) => {
    nuxtApp.vueApp.directive('highlight', {
        mounted(el, binding) {
            el.style.backgroundColor = binding.value
        }
    });

    // Register more directives as needed
});

Our plugin function has access to the Nuxt app context, which has a vueApp property containing our Vue app instance. We can directly register our directives on this property and have it globally available throughout our app.

It's important to note that, to avoid issues with server-side rendering (SSR), our plugin file should not contain a .client or .server suffix when used to register directives.

That's it. Thanks for reading.

👨‍💻 Let's Connect › Twitter · GitHub · LinkedIn

Using Nuxt Content: Working with Remote Markdown Files

Dawit — Mon, 15 Apr 2024 15:30:00 +0000

This article discusses how to get started with Nuxt Content to create a minimal blog, and how to work with remote Markdown files.

The first section goes over how to set up a project with Nuxt Content, and the second cover working with Markdown files. If you are already familiar with the setup steps, feel free to skip the first section.

Get Started

What is Nuxt?

Nuxt is an open-source framework for building performant websites and full-stack applications using Vue.js. It provides performance and SEO benefits, and adds full-stack capabilities for Vue apps.

Nuxt is an appealing framework to work with, partly because of its robust module ecosystem. Popular UI libraries, headless CMS tools, and databases can be easily integrated with a single line of code. Among other third-party modules, Nuxt Image, Nuxt Content, and Nuxt UI are some of the official modules developed by the Nuxt team.

What is Nuxt Content?

Nuxt Content is a file-based CMS that makes working with content easier for Vue developers. Using this module, it is possible to create fully content-driven websites using just Markdown files. It provides syntax highlighting for code snippets in Markdown, interactive Vue components inside content and different utilities including a MongoDB-like API for querying content.

The Nuxt team also offers Nuxt Studio - a pro version of Nuxt Content - with features like collaborative editing, live previews and a UI for working with media assets.

Setup

To start a fresh Nuxt Content project, we can do so right in the browser using nuxt.new, or locally by running the following command:

npx nuxi@latest init -t content my-minimal-blog

To integrate the module to an existing project, we need to first install it and add it to the modules property in our nuxt.config.js:

npm install @nuxt/content

export default defineNuxtConfig({
  modules: ["@nuxt/content"]
});

Basics

We can configure multiple sources for content in nuxt.config.js. By default, all content files are stored in the content/ folder, and can be in the form of Markdown, YAML, JSON or CSV.

To get started, let's create some content, and ensure we have a catch-all route set up.

A catch-all route should already be created by default if we are setting up a Nuxt Content project from scratch, and here is what it looks like initially:

<!-- pages/[...slug].vue -->
<template>
  <main>
    <ContentDoc />
  </main>
</template>

<ContentDoc> is a built-in component that takes care of all the fetching and rendering functionality for a single piece of content such as a blog post.

Next, let's create some Markdown files with some content:

content/Nuxt.md

---
title: Nuxt
description: What is Nuxt?
---

# What is Nuxt?

Nuxt is an open source framework that makes web development intuitive and powerful.

[Learn More](https://nuxt.com)

content/Nuxt Content.md

---
title: Nuxt Content
description: What is Nuxt Content?
---

We can also access our front-matter data in our Markdown.

# {{ $doc.description }}

Nuxt Content makes working with content easy for Vue Developers.

[What is Nuxt?](/nuxt)

Nuxt Content will then automatically process our content folder, and generate file-based routes for each content. The file located at content/Nuxt.md will be available at /nuxt, content/Nuxt Content.md at /nuxt-content, and so on.

That's it. We now have a minimal yet fully-functioning blog built with Nuxt Content.

Remote Content

This section will go over how to configure Nuxt Content to work with remote content, specifically with Markdown files from a GitHub repo.

Nuxt Content provides some useful configuration options for fetching, parsing and rendering content. We can configure our Markdown content to have a table of contents and anchor links for our headings. We can add plugins for customizing parsing behavior. We can customize syntax highlighting for our code snippets. We can even set different sources for our content.

Content-related configurations can be set using the content property in nuxt.config.js file.

// nuxt.config.js
export default defineNuxtConfig({
    content: {
        // Custom Configurations
    }
});

By default, Nuxt Content is configured to look for local files inside the content/ directory. But, using the sources option, we can tell the module to look for files in different places, which can either be other local files or files hosted on a remote server. Although it's not recommended, we can also override the default content location for local files.

export default defineNuxtConfig({
    content: {
        sources: {
            blog: {
                driver: 'fs',
                prefix: '/blog',
                base: resolve(__dirname, 'articles')
            },
            github: {
                driver: 'github',
                prefix: '/notes',
                repo: "oneminch/notes",
                branch: "main",
                dir: "Glossary"
            },
        }
    }
});

In the above snippet, we have added two new sources for our content: one local source and one remote (GitHub). The type of source added is indicated by the driver option in our source object:

The fs driver stands for filesystem and indicates our content source is local to the project.
The github driver allows us to map files from a remote GitHub repo to our local project.

Side Note: Nuxt Content uses unstorage under the hood to make this possible. Other types of drivers can be configured according to the unstorage documentation.

Let's see what the github configuration above does in action.

Nuxt Content will parse all the markdown files located in the GitHub repo oneminch/notes under the Glossary folder (given by the dir property), and make all files available under the /notes path (indicated by the prefix property).

For instance, in the repo, I have Markdown files titled Hoisting.md and Server-Side Rendering.md in the Glossary folder. According to our configuration, the contents of these files will be available at the paths /notes/hoisting and /notes/server-side-rendering respectively, just as working with local content.

We can also use our prefix in different parts of our code that require a path for fetching data.

Using the queryContent() composable:

<script setup>
const { data: notes } = await useLazyAsyncData("my-notes", () =>
    queryContent("/notes").find()
);
</script>

Using the <ContentList> component:

<template>
    <ContentList path="/notes">
        <template #default="{ list }">
            <a v-for="note in list" :key="note._path" :href="note._path">
              {{ note.title }}
            </a>
        </template>
        <template #not-found>
            <p>No notes found.</p>
        </template>
    </ContentList>
</template>

One thing to note is that since Nuxt Content is basically making API calls to GitHub every time we are fetching content, our requests might get rate limited by GitHub. So, it's generally recommended to add a GitHub API token to our configuration following the unstorage configuration options.

export default defineNuxtConfig({
    content: {
        sources: {
            github: {
                /* ... */
                token: process.env.GH_TOKEN
            }
        }
    }
})

That's it. If you would like to learn more, check out the resources below. Thanks for reading.

Learn More

The JavaScript Fetch API

Dawit — Wed, 25 Oct 2023 12:00:00 +0000

One of the ways of making HTTP requests in JavaScript is the fetch() API. The fetch() API is a modern JavaScript API that allows web developers to send/retrieve data across the web.

Imagine a scenario where you enter a coffee shop. You go to your barista, and ask for a cappuccino. The barista enters your order on their computer or passes your order along to the other barista. After making your payment, you then wait for your order to come. If it comes, you can start enjoying your coffee. And if there was a miscommunication between you, and the barista, you might get a drink you didn't intend to order.

In the above analogy:

Your order is the request.
The endpoint is the barista at the coffee shop.
The coffee is equivalent to the data/resource we want to retrieve.
A successful order is a resolve.
A miscommunication can lead to you getting the wrong drink, which is an error.

Diving Deeper into `fetch()`

Parameter: a required URL/path to the data you want to fetch, and a set of other options

Return value: a 'Promise' (which is a result that is expected to arrive) that resolves to a 'Response'

For example, GitHub offers an API to retrieve some data about its users. A simple request using this API will look like this:

// JavaScript Code
fetch("https://api.github.com/users").then(function (res) {
  /* Code to be executed */
});

In this case, the https://api.github.com/users is the path to the resource we want to fetch. This particular URL returns or resolves basic information about 30 GitHub users in the form of a JavaScript object.

After sending the request, a Promise is returned. A Promise is an object that results in a value some time in the future. It can be in 3 possible states: pending, fulfilled, or rejected.

Fulfilled: is a state where the request has been handled successfully, and a response is sent back.
Rejected: is a state where the request has been denied access to that resource or when there is a network error.
Pending: is a state where the request is sent, and it isn't fulfilled or rejected yet.

When a Promise gets fulfilled, the then() method can be called to deal with what happens next. It takes in the response received from the request as an argument. The code that is to be executed on this response goes in this block. This method can be chained together to perform a series of tasks which execute once the corresponding previous then() block has finished executing. It follows the order of "Let this block finish executing...then execute this...then execute that...".

Going back to our previous example, after retrieving our user list data from the GitHub API, we can convert that data into JSON format. Then we can simply log it to the console or write a function that could display this data on an HTML page.

// JavaScript Code

fetch("https://api.github.com/users")
  .then(function (res) {
    return res.json(); // Convert the data into JSON
  })
  .then(function (data) {
    console.log(data); // Logs the data to the console
    return data;
  });

A Promise can get rejected for any of these reasons:

The resource/data we requested didn't exist,
We're not authorized to access it, or
We used the wrong URL to the resource.

In such a case, an error will occur. It is important that these errors are dealt with. That's where the catch() block comes in.

The catch() block is chained at the end of the then() blocks, and it is where error handling is performed. It takes an error object as an argument.

// JavaScript Code

fetch("https://api.github.com/users")
  .then(function (res) {
    return res.json(); // Convert the data into JSON
  })
  .then(function (data) {
    console.log(data); // Logs the data to the console
  })
  .catch(function (error) {
    console.log(err); // Logs an error in case there is one
  });

A Few More Examples

This code uses a fake REST API called JSONPlaceholder. According to the documentation of this API, a fetch request returns an array of objects. In this particular case, the code fetches a fake user (object) from a list (array) of users, but it only returns the one with an id of 2.

Code:

// JavaScript Code

fetch("https://jsonplaceholder.typicode.com/users/2")
  .then(function (res) {
    return res.json(); // Convert the data into JSON
  })
  .then(function (data) {
    console.log(data); // Logs the data to the console
  })
  .catch(function (error) {
    console.log(err); // Logs an error in case there is one
  });

Output:

    {
        "id":2,
        "name":"Ervin Howell",
        "username":"Antonette",
        "email":"Shanna@melissa.tv",
        "address":{
            "street":"Victor Plains",
            "suite":"Suite 879",
            "city":"Wisokyburgh",
            "zipcode":"90566-7771",
            "geo":{"lat":"-43.9509","lng":"-34.4618"}
        },
        "phone":"010-692-6593 x09125",
        "website":"anastasia.net",
        "company":{
            "name":"Deckow-Crist",
            "catchPhrase":"Proactive didactic contingency",
            "bs":"synergize scalable supply-chains"
        }
    }

From the output, it's clear that a user is an object with a set of properties. We can continue to chain other then() blocks to perform more tasks on the data we want.

Code:

    // JavaScript Code

    ...
    .then(function(data) {
        const { name, company: { name: companyName }, website } = data

        console.log(
            `My name is ${name}. I work at ${companyName}.
            For more info, you can visit my blog @ ${website}`
        );
    })
    ...

Output:

My name is Ervin Howell. I work at Deckow-Crist.
For more info, you can visit my blog @ anastasia.net.

The web runs on requests, and modern web-native tools like the fetch API help programmers avoid building things from scratch.

HTTP Requests in JavaScript

Dawit — Tue, 24 Oct 2023 12:00:00 +0000

Making requests is the heart of the Internet. Whenever you are browsing the internet, all what you are doing is requesting information from servers, which are basically interconnected computers. It's the foundation of how websites work. A simple case is a person typing "www.duckduckgo.com" and getting the DuckDuckGo search page. A request is made to a web server, which then sends back the files for that page, which will be rendered in the browser as a web page. This is made possible by a protocol known as HTTP (HyperText Transfer Protocol). On MDN web docs, the HTTP protocol is described as:

HTTP is a protocol which allows the fetching of resources, such as HTML documents. It is the foundation of any data exchange on the Web, and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is reconstructed from the different sub-documents fetched, for instance text, layout description, images, videos, scripts, and more.

Requesting a resource from the client side uses this HTTP protocol, and these types of requests are known as HTTP requests. These requests are essential for any type of online activity performed on the web.

JavaScript has a set of great tools and methods that allow us to make HTTP requests to send or receive data from a certain server or endpoint. A couple of commonly used ways to make requests are XMLHttpRequest and Fetch.

1. XMLHttpRequest (XHR)

AJAX stands for Asynchronous JavaScript And XML. Requests made are asynchronous, which means they don't interrupt the execution of other JavaScript code. In other words, JavaScript code besides the AJAX code doesn't have to wait for requests to finish being executed. It can execute simultaneously. The method that makes this possible is the XMLHttpRequest(). Despite the prefix 'XML', we can process any form of data for our requests.

The XMLHttpRequest() method works as a constructor for us to create an instance and call our AJAX requests on.

const xhr = new XMLHttpRequest();

Our xhr object has a number of methods and properties that allow us to make different types of requests.

Methods

xhr.open()

We can then use the open() method on our xhr object to initialize or configure a request. This method takes the following parameters:

Method: GET, POST, PUT or DELETE,
URL: Path to our resource,
Async: Boolean value (true or false); Optional & default value is true,
Username & Password — Optional; Credentials if authentication is needed.

It follows the syntax:

xhr.open(Method, URL[, Async]);

xhr.send()

This method allows us to open and send our request. It takes an optional parameter that contains our request body, which is useful when making POST requests.

xhr.send([body]);

xhr.setRequestHeader()

This method is used to set HTTP headers for our request, such as Content-Type & Accept. Similarly, we can use xhr.getResponseHeader() to get header values from our response.

// Set header for request
xhr.setRequestHeader("Content-Type", "application/json");

// Get header for response
xhr.getResponseHeader("Content-Type");

xhr.abort()

This method is useful when we want to cancel a request. Imagine a scenario where a user wants to cancel a request because it's taking too long. xhr.abort() can be used to stop the request.

xhr.abort();

Properties

xhr.response

This value contains the response body we receive from our request. xhr.responseText is also a similar property, which is used if our response is in a string format.

const res = xhr.response;

xhr.responseType

This is used to set the response type for our xhr object. It can be in any one of these formats:

text/"" - default value
json
document
blob

xhr.responseType = "json";

xhr.readyState

Our request changes states as it progresses, and the current state of our request can be accessed by this property. Its values range from 0 (initial state) to 4 (completed state). The event onreadystatechange can be used to detect whenever there is a change in state.

xhr.onreadystatechange = function () {
  if (xhr.readyState == 1) {
    /* request opened */
  }
  if (xhr.readyState == 2) {
    /* headers received */
  }
  if (xhr.readyState == 3) {
    /* response loading */
  }
  if (xhr.readyState == 4) {
    /* request complete */
  }
};

Events

xhr.onload

This event is fired when our request is successful and the result is sent back. This can also be computed with xhr.onreadystatechange when xhr.readyState is 4.

xhr.onload = () => {
  // Code to run when results are ready
};

xhr.onerror

This event is invoked when there is an error in our request, which could be due to network error or invalid configuration of our request.

xhr.onerror = () => {
  // Code to run when request has failed
};

xhr.onprogress

This event is called repeatedly while our request is processed. It can be used to figure out the loading progress of a download or even a page load to let the user know how far along their request has been processed. An event parameter can be passed to xhr.onprogress and it has properties event.loaded and event.total, which can be used to show the actual progress feedback.

xhr.onprogress = (event) => {
  // Code to run while request is being processed
  console.log(`Loaded ${event.loaded} of ${event.total}`);
};

Example

We are going to use a simple fake online REST API called JSONPlaceholder to make example requests. We will use it to request and submit fake posts. According to the documentation for JSONPlaceholder, our path to the resource we want is https://jsonplaceholder.typicode.com/<endpoint>, and there are several endpoints to choose from. For this demo, we'll use 'posts' as our endpoint. For this certain endpoint, we are going to receive and submit to an array of posts which are enclosed in objects. We also want our request to be asynchronous.

Method: GET - is used to retrieve data.

// Our path to the resource
let reqURL = "https://jsonplaceholder.typicode.com/posts";

// 1. CREATE OUR XHR OBJECT
const xhr = new XMLHttpRequest();

// 2. SET OUR RESPONSE TYPE
xhr.responseType = "json";

// 3. CONFIGURE OUR REQUEST
xhr.open("GET", reqURL, true);

// 4. SEND THE REQUEST
xhr.send();

// 5. DECLARE FUNCTIONS BASED ON EVENTS
xhr.onload = () => {
  const data = xhr.response;
  console.log(data);
};

xhr.onprogress = (event) => {
  console.log(`Loaded ${event.loaded} of ${event.total}`);
};

xhr.onerror = () => {
  console.log("Request failed!");
};

As an output, we get a list of objects in the form of an array.

// An example object from the array we get
{
    id: 1,
    title: "sunt aut facere repellat provident occaecati excepturi",
    body: "quia et suscipit suscipit recusandae consequuntur expedita et cum reprehenderit ...",
    userId: 1
}

Method: POST - is used to send new or updated data to the specified resource.

// Our path to the resource
let reqUrl = "https://jsonplaceholder.typicode.com/posts";

// 1. CREATE OUR XHR OBJECT
const xhr = new XMLHttpRequest();

// 2. Configure a `POST` request
xhr.open("POST", reqUrl);

// 3. Create a JSON 'post' object
const json_data = {
  title: "this is title",
  body: "this is body",
  userId: 1
};

// 4. Set the `Content-Type` header
xhr.setRequestHeader("Content-Type", "application/json");

// 5. Pass a string form of our
//    json_data object to `send()`
xhr.send(JSON.stringify(json_data));

// 6. DECLARE FUNCTIONS BASED ON EVENTS
xhr.onload = () => {
  const data = xhr.response;
  console.log(data);
};

xhr.onprogress = (event) => {
  console.log(`Uploaded ${event.loaded} of ${event.total}`);
};

xhr.onerror = () => {
  console.log("Request failed!");
};

Other than the couple of steps we have added, the general structure and process of making HTTP requests is very similar and perhaps even almost identical.

For our demo API, the object we 'posted' is not actually added to their database of posts. Since it is a fake API, the process is also faked, as the purpose of this code and the API is to demonstrate how requests work and to test code.

Method: PUT - is used to update or modify data at the specified path. This is almost identical to our POST method process. The only things that change are the path, the method name and the object we are updating. Other than these values, the rest is the same.

// 1. Our path to the object we want to update
//    Notice the '/1' added to the end
let reqUrl = "https://jsonplaceholder.typicode.com/posts/1";

// Configure a `PUT` request
xhr.open('PUT', reqUrl);

// Create a JSON 'post' object
// We added 'id' so it can be used to
// update the entry with the specified id
const json_data = {
    id: 1
    title: 'this is updated title',
    body: 'this is updated body',
    userId: 1
};

Method: DELETE - is used to delete the specified resource. Based on the documentation for the API, we use a different path to our resource to target and delete an entry.

// 1. Our path to the object we want to delete
//    Notice the '/1' added to the end
let reqUrl = "https://jsonplaceholder.typicode.com/posts/1";

// 2. CREATE OUR XHR OBJECT
const xhr = new XMLHttpRequest();

// 3. Configure a `DELETE` request
xhr.open("DELETE", reqUrl);

// 4. SEND THE REQUEST
xhr.send();

For real APIs, we can continue to create another GET request to verify that the data we wanted to delete is actually deleted. We can retrieve all the data and see if the object we sent a DELETE request on is in the database. If it's not, then the data is deleted.

2. Fetch

Fetch is a promise-based web API. It is a modern alternative to XHR. I have explained in detail how the fetch() API works here. But let's redo the previous requests using fetch and see the difference.

Method: GET

let reqUrl = "https://jsonplaceholder.typicode.com/posts";

fetch(reqUrl)
  .then((res) => res.json())
  .then((data) => console.log(data))
  .catch((error) => console.log(error));

Method: POST

fetch(reqUrl, {
  method: "POST",
  body: JSON.stringify({
    title: "this is title",
    body: "this is body",
    userId: 1
  }),
  headers: {
    "Content-type": "application/json"
  }
})
  .then((res) => res.json())
  .then((data) => console.log(data))
  .catch((error) => console.log(error));

Method: PUT

// Our path to the object we want to update
let reqUrl = "https://jsonplaceholder.typicode.com/posts/1";

fetch(reqUrl, {
  method: "PUT",
  body: JSON.stringify({
    id: 1,
    title: "this is title",
    body: "this is body",
    userId: 1
  }),
  headers: {
    "Content-type": "application/json"
  }
})
  .then((res) => res.json())
  .then((data) => console.log(data))
  .catch((error) => console.log(error));

Method: DELETE

// 1. Our path to the object we want to delete
let reqUrl = "https://jsonplaceholder.typicode.com/posts/1";

fetch(reqUrl, {
  method: "DELETE"
});

Fetch is a much cleaner and simpler way of doing what XHR allows us to do. Tracking progress is not yet supported in fetch. Due to that and many other reasons like browser support, XHR is still an important part of making requests.

There are also third-party tools such as axios and jQuery's $.ajax(). These utilize XHR and/or Fetch API under the hood to provide a much cleaner way of making requests for developers.

The JavaScript Fullscreen API

Dawit — Mon, 23 Oct 2023 12:00:00 +0000

Whenever you want to watch a YouTube video, play a video game or just want to do a focused work in your browser, the fullscreen feature makes the experience even more immersive. This article explains how this particular API works in JavaScript and how you can easily implement one in your projects.

Introduction

The Fullscreen API allows an element on a page to be viewed in fullscreen. It makes it convenient for users to view web content in full pixel width and height. Aspects of the browser UI and OS, such as status bars, menu bars, as well as any applications on the device that take up screen space, are hidden. It accomplishes this by calling a method on an HTML tag that we want to view in fullscreen mode.

When viewing a video in a browser in fullscreen, it's a <video> tag that is actually in fullscreen mode. If the item we are viewing is an image, it's the tag that contains the image (usually the <img> tag) that is in fullscreen.

Basically, this API is a simple one to implement. However, it doesn't have one universal way of implementation. The methods used and events fired by the API may vary from browser to browser, especially in older versions of browsers. Inconsistencies as such, which are very common in the programming world, make this API a bit lengthy to write despite its simplicity.

For example, consider the following HTML code:

<video id="intro" controls>
  <source src="intro.webm" type="video/webm" />
  <source src="intro.mp4" type="video/mp4" />
</video>

We can then simply call the method requestFullscreen() on the video element. The method is applied to an Element interface (and its child elements) to present it in fullscreen. This method can also be used to check whether fullscreen is available on this particular element. To exit fullscreen mode, the exitFullscreen() method is called on the Document interface. As in the case of the previous method, this method can also be used to check if it's supported on the document or in the browser.

    const el = document.querySelector("#intro");
    if (el.requestFullscreen) {
        el.requestFullscreen();
    }
    ...
    if (document.exitFullscreen) {
        document.exitFullscreen();
    }

The Document interface has built-in properties that can help us determine:

If fullscreen mode is available/supported (document.fullscreenEnabled).
Which element in the DOM is in fullscreen mode if fullscreen mode is active (document.fullscreenElement).

Events

Two events are defined by the API:

document.onfullscreenerror - fired on the Document whenever an error occurs when trying to enter or exit fullscreen mode.
document.onfullscreenchange - fired whenever there is a change in fullscreen status on the entire Document, whether it's entering or exiting fullscreen, or switching tabs while in fullscreen mode.

    document.addEventListener("fullscreenerror", () => { ... });
    ...
    document.addEventListener("fullscreenchange", () => { ... });

CSS

We can further customize the element when it is in fullscreen mode using CSS. The :fullscreen CSS pseudo-class can be used to style an element that is currently in fullscreen mode. As with the case of many pseudo-selectors, we need to consider browser support with CSS, since it is not supported in all browsers.

#intro:-webkit-full-screen {
  ...;
}
#intro:-moz-full-screen {
  ...;
}
#intro:-ms-fullscreen {
  ...;
}
#intro:fullscreen {
  ...;
}

A Detailed Example

function toggleFS() {
  /*  
    Checks if there is an element in
    fullscreen mode(including browser support)
  */
  if (
    !document.fullscreenElement &&
    !document.webkitFullscreenElement &&
    !document.mozFullScreenElement &&
    !document.msFullscreenElement
  ) {
    /*  
      Checks if fullscreen is available for the
      selected element and calls the method
      ('else if' blocks ensure browser support)
    */
    if (el.requestFullscreen) {
      el.requestFullscreen();
    } else if (el.webkitRequestFullscreen) {
      el.webkitRequestFullscreen();
    } else if (el.mozRequestFullScreen) {
      el.mozRequestFullScreen();
    } else if (el.msRequestFullscreen) {
      el.msRequestFullscreen();
    }
  } else {
    /*
      Exits fullscreen mode
      ('else if' blocks ensure browser support)
    */
    if (document.exitFullscreen) {
      document.exitFullscreen();
    } else if (document.webkitExitFullscreen) {
      document.webkitExitFullscreen();
    } else if (document.mozCancelFullScreen) {
      document.mozCancelFullScreen();
    } else if (document.msExitFullscreen) {
      document.msExitFullscreen();
    }
  }
}
const el = document.querySelector("#fs-btn");
el.addEventListener("click", toggleFS);

The fullscreen API is a very simple and handy tool for developers to apply to their web applications. It makes content more immersive, and help users with smaller screens to view content conveniently on their devices.

Fullscreen API - MDN

How Deno differs from Node.js

Dawit — Tue, 01 Aug 2023 00:10:21 +0000

Deno improves upon Node.js in some significant ways.

Modules

Modules are loaded directly from URLs and cached locally.

import confetti from "https://esm.sh/canvas-confetti@1.6.0";

This allows the decentralization of packages by removing reliance on npm and enabling developers to self-host their packages.

Consequently, this removes the need for package.json and node_modules, and allows programs to run in the browser since there is no reliance on build tools like Webpack.

Security

Because code is executed in a sandbox, the Deno runtime has no access to the file system and the network. Flags like --allow-write and --allow-net can be used to explicitly enable access.

Other Features

In addition to the above features, Deno supports TypeScript out of the box and has a built-in formatter for code similar to ESLint for Node.js.

HTTPS Basics

Dawit — Mon, 28 Mar 2022 19:39:10 +0000

Outline

Drawbacks of HTTP
The Solution: HTTPS
HTTPS = HTTP + SSL
Limitations of HTTPS
References

HTTPS is a protocol which is an improvement over HTTP and is the short form of Hypertext Transfer Protocol Secure (HTTP + SSL). In this article, we will look at the shortcomings of HTTP which lead to the development of HTTPS and some basic ideas behind HTTPS. It'll cover these sub topics:

Drawbacks of HTTP
HTTPS as the solution
HTTPS = HTTP + SSL
Limitations of HTTPS

As introduced in this article about HTTP, HTTP is a protocol of the web that allows communication between devices. It is the technology behind the requests and responses made on the web. Once the client device has identified the server address, it works by opening a connection tunnel to the server, so the intended requests are made.

Drawbacks of HTTP

HTTP requests are not considered safe since they can be easily intercepted and manipulated by anyone on the network. A very common analogy to describe plain HTTP is the use of pipes as a means of communication. Imagine a transparent glass pipe that connects two points. Everything sent between anyone from one point to the other can be seen passing through the pipe. A person standing in the middle can see the things passing through the transparent pipe. This is how plain HTTP requests work. There is no layer of security to hide the contents of requests and responses. Data can be tampered with or snooped on by a third party on the network like Internet Service Providers (ISPs), malicious hackers or even employers. Therefore, sensitive data like financial information and website passwords should not be transferred over just HTTP.

Another drawback is that someone on the network can manipulate the requests, so they can insert ads, or inject code to serve phishing sites or just steal user information. In HTTP, if you visit a site, let's say, a shopping site, there is no way to actually verify that the site that you are visiting is the site you wanted to visit. In other words, the website you get if you wanted to go to http://dev.to, might not be the actual website. It can be a forged site injected by some entity along the network to trick users into giving away personal information. All these problems make plain HTTP a less ideal way to communicate on the web.

The Solution: HTTPS

This is where HTTPS comes in. HTTPS is an extension of HTTP, and it makes sure the there is a secure communication over the network. HTTPS is not actually a separate protocol from HTTP. It is the same protocol except the connection is encrypted, unlike plain HTTP where the connection is unencrypted. Request and response messages include components like headers and a body. All data like request messages get encrypted before they leave the sender. Going back to our pipe analogy, HTTPS can be imagined as being an opaque metal or plastic pipe. This means that the contents of the messages transferred are hidden from visibility and manipulation.

HTTPS = HTTP + SSL

HTTPS uses a cryptographic protocol known as TLS (Transport Layer Security) to encrypt transactions. Originally, what it used was known as SSL (Secure Sockets Layer), which later evolved to TLS. Thus, it's sometimes referred to as HTTP over SSL or HTTP over TLS. Even though SSL and TLS refer to different versions of the same protocol, the terms are often used interchangeably. This protocol ensures data security when it is transferred over a network, which means protection from issues like potential eavesdropping and man-in-the-middle attacks because of end-to-end encryption between client and server.

In addition to protecting eavesdropping, HTTPS guarantees the request/response is delivered to the right recipient. It verifies the authenticity of all the entities involved in the process. For a website to be secured with HTTPS in a user's browser, it needs to provide a form of authentication to prove that it is the actual website that belongs to the actual server. To ensure this, it requires the server to install what is known as a certificate, which is a unique cryptographic key and have it signed by an entity known as a certificate authority. The administrator of the website can ask the certificate authority to issue a certificate. In other words, a certificate is a way of saying if a browser is opened at https://duckduckgo.com, then it is really on the official site for DuckDuckGo.

As mentioned above, SSL is the protocol used for transmitting data over the Internet securely. Before getting to the request and response transaction over SSL, a server needs to prove it is the legitimate one the client wants to communicate with. The server sends its SSL certificate to the browser, which then checks if that server is who it says it is. Once the browser has verified the identity of the server, they use cryptographic keys to proceed with the data exchange.

This video explains well how SSL encryption works.

Limitations of HTTPS

However, HTTPS has its limitations. Domain names and IP addresses are not secure when using HTTPS. This is part of the reason why the use of VPNs is advised when using public wireless networks to mask IP addresses.

HTTPS is becoming adopted by more and more websites every day. Modern browsers like Firefox and Chrome warn users if a website has an invalid certificate or if the connection is not secure (if it uses http:// instead of https://). They use a lock icon to the left of each URL to indicate if the site is authenticated and if it uses HTTPS. Latest versions of these browsers even ask twice before navigating to insecure sites. Tools like Firefox's built-in HTTPS-Only Mode and extensions like HTTPS Everywhere work by rewriting an insecure HTTP request to HTTPS. And with services like Let's Encrypt, enabling HTTPS on sites is becoming more convenient.

References

HTTP Basics

Originally posted on OpenGenus IQ

HTTP Basics

Dawit — Sun, 20 Mar 2022 02:31:05 +0000

Outline

Terminology
How actually are requests made?
1. Start Line
2. Headers
3. Body
A few more examples
HTTPS
References

In this article, I will discuss how HTTP requests work behind the scenes.

Before we delve deeper into this topic, let's see an overview of how the web works. When a person wants to visit a website, they type in the address of the site into their browser or client (for instance iq.opengenus.org). The web addresses typed into URL bars are not actual addresses of the sites. The actual web addresses are in the form of IP addresses (like 159.89.134.55). But memorizing these addresses is not convenient for each website a person wants to use.

This is why DNS (Domain Name System) servers exist. You can imagine these servers as the phone books of the Internet. Computers use IP addresses to identify and communicate with each other. When someone requests a website, the browser contacts a DNS server. The DNS server then tells the browser the IP address associated with the computer or server that hosts the requested site. This is the address of the device where the documents and files for that site are hosted. The files necessary get sent back to the browser and get assembled and rendered by the browser as the websites we use every day.

Terminology

Client here refers to the computer asking for service by making requests - e.g. to make a search or to check news

Server is the computer, that is usually located somewhere else, holding the things necessary to provide those services. It is responsible for sending responses to requests.

How actually are requests made?

Requests on the web are made through a set of steps and make use of a protocol known as HTTP. HTTP stands for HyperText Transfer Protocol. It is used for communication between the client and the server(s). It is the foundation of the Internet. HTTP uses the URL typed into the browser to identify the resource wanted and to make a connection.

When requesting a site, the URL looks something like this http://duckduckgo.com. Using the URL provided, the browser identifies the request needs to be made through http and the domain name for the web address is duckduckgo.com which it then sends to a DNS server to get the IP address of the server the site is hosted on. Once the client (browser) knows the IP address of the destination server, it opens a connection channel to it and makes the request needed. All this process is only the initial part of the steps taken to make the request.

Request messages are exchanged between the client and server to fulfill that request, and they usually follow a similar format. They contain 4 components: a start line, headers followed by an empty line to indicate the end of headers and an optional body.

Below is an example of a typical GET request message. This is similar to what you would usually see if you open the Network tab from your browser Dev Tools.

GET /tag/algorithm HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT) Gecko/20100101 Firefox/73.0
Host: iq.opengenus.org
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

1. Start Line

This is the first line of a message describing the requests to be implemented.

For a request, this line contains these values separated by a space: method, request URI and HTTP version followed by a new line.

Method indicates the type of request to be made and common values include: GET, HEAD, POST, PUT, and DELETE.
HTTP Version is the version of HTTP, usually HTTP/1.0 or HTTP/1.1.
Request URI is the path to the resource upon which the request is to be made. It can be either an absolute URI or a relative URI.

Examples are shown below.

/ - is a relative URI meaning root path. We are not navigating any further. We have identified the host, and we are making request on the root.

GET / HTTP/1.1
Host: iq.opengenus.org

https://iq.opengenus.org/tag/algorithm - is the absolute URI.

GET https://iq.opengenus.org/tag/algorithm HTTP/1.1

/tag/algorithm - is a relative URI meaning we are navigating to this path from the host or root path which is iq.opengenus.org.

GET /tag/algorithm HTTP/1.1
Host: iq.opengenus.org

For a response, the template is composed of these values separated by a space: HTTP version, status code, and a reason phrase.

HTTP Version is the version of HTTP, usually HTTP/1.0 or HTTP/1.1.
Status Code is a 3 digit integer indicating the status of our response. These can be in any one of 5 classes:
- 100 - 199: Informational
- 200 - 299: Success
- 300 - 399: Redirection
- 400 - 499: Client Error
- 500 - 599: Server Error
Status Phrase follows the status code and is a short summary of the status of the response.

HTTP/1.1 200 OK
HTTP/1.1 404 Not Found

2. Headers

Headers follow the start line, and they allow the client to pass additional information about the request or the client itself to the server, or they allow the server to pass additional information about the response to the client. They usually appear as key-value pairs. Headers can be:

General headers - applicable to both requests and responses.
Request headers - applicable to only requests sent by the client.
Response headers - applicable to only responses sent by the server.
Entity headers - applicable to message body (if there is any).

Some common headers are listed below:

General	Request	Response	Entity
cache-control	accept	age	allow
connection	cookie	location	content-length
date	host	retry-after	expires
upgrade	user-agent	server	last-modified
via	DNT	set-cookie	content-type

Header fields ensure requests and responses are made just the way the client and server want. In other words, header fields are a means of communication between a client and a server with specific details given to fulfill the request.

Caching is one method which makes this whole process more convenient for the devices involved. It improves performance by removing the need for a client to send any or some requests, or the need for a server to send back any or some responses. It does so by using the cache-control header field.

Content types are important in enforcing the data types sent to a server or sent back from a server are in alignment with each other. Header fields like accept and content-type are a means of communicating the types of files and documents involved in a request.

Client details like the type of hardware and versions of software are also important in delivering an optimized experience. The user-agent header field passes detailed information about the client to the server, so that the server can send back the necessary files for the request. Due to compatibility issues, the files necessary for a service to work on one device may be completely different from another device. Identifying device types using this header field helps the process.

3. Body

If our message has a body, it is preceded by an empty line which come after the headers. The empty line indicates the end of header fields. The message body carries actual data for a request from a client (e.g. form data when authenticating) or a response from a server (e.g. files and images).
A simple line of code can be passed after the empty line as the body of a request or a response. The following two examples show server responses: when the requested resource is found and when it's not found.

HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html
Connection: Closed

<html>
    <body>
        <h1>Hello, Friend!</h1>
        <p>Nice to see you!</p>
    </body>
</html>

HTTP/1.1 404 Not Found
Server: nginx
Content-Type: text/html
Connection: Closed

<html>
    <body>
        <h1>File Not Found</h1>
        <p>Sorry friend, the requested resource wasn't found</p>
    </body>
</html>

To get a closer look at requests in your browser, you can navigate to 'Network' tab of your browser's Developer Tools, or just hit Cmd + Opt + E on Mac or Ctrl + Shift + E on Windows and Linux. Type the URL to any website and see all the requests and responses made. Usually there are several requests and responses made. Each request fetching a single file that is a component of the website to be rendered.

The above image shows a detailed look at what goes on behind the scenes when navigating to the DuckDuckGo website. As you can see in the bottom left corner, there were a total of 29 GET requests made. File types range from simple HTML, CSS & JavaScript files to images and font files. Greyed out rows indicate the requests has been cached from previously made requests. The right section of the image shows the details of the first request which fetches the HTML file for the website. Consecutive rows show the order by which the other file types are loaded. When working with requests, it's important to make sure the necessary files come first. In this case, the HTML file is the most relevant file. For users whose connection might be interrupted easily, having the HTML file is enough to make the search. All the CSS, images and font files are secondary, and they're not really necessary for someone to make a search on DuckDuckGo.

A few more examples

In this one, we are using POST method to make searches on DuckDuckGo. The request looks like this:

POST https://duckduckgo.com HTTP/1.1
Accept: text/html
Accept-Language: en-US
Connection: keep-alive
Content-Length: 18
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT) Gecko/20100101 Firefox/73.0

q=opengenus

PUT method is very similar to POST but it is used to update resources.

PUT /update.html HTTP/1.1
Host: website.com
Content-type: text/html
Content-length: 26

<p>File to be updated</p>

The DELETE method can be used to delete a given resource.

DELETE /resource.html HTTP/1.1

The server can send back a response notifying the client about the completion of the DELETE request.

HTTP/1.1 200 OK

<html>
  <body>
    <h1>Resource successfully deleted.</h1>
  </body>
</html>

HTTPS

HTTP requests can be easily intercepted or read by anyone at any point in the network. Therefore, sensitive information like credit card numbers and passwords should never be delivered using HTTP. Instead, an extension of HTTP known as HTTPS (HyperText Transfer Protocol Secure) is used. It creates a secure channel over the network so that encrypted data is transferred between the client and the server. This provides protection from potential eavesdroppers or man-in-the-middle attacks. This is one of the parameters your browser uses to notify you if a website is secure or not.

References

HTTP - Mozilla Developer Network

Originally posted on OpenGenus IQ

Domain Name System (DNS) Basics

Dawit — Mon, 21 Feb 2022 06:05:40 +0000

Outline

Introduction
How DNS Works
DNS over HTTPS (DoH)

Introduction

When a user makes any form of request on a network such as a website by typing the URL, all the user is asking is the files associated with that URL. To fetch these files, the client needs to know which computer (server) on the Internet they are being hosted on and open a secure connection to that computer. On a network, computers and different network devices can't identify and locate one another using names. Instead, they communicate with each other using what is known as IP addresses. Therefore, the client needs to know what the IP address of the server is. Since users can't memorize the IP address of each website they're using, the client needs a way of figuring out what IP address is associated with the given URL. This system of mapping or translating domain names to corresponding IP addresses is known as the Domain Name System or DNS.

The Domain Name System is a distributed database of hostname to IP address mappings. It is updated whenever someone purchases and register a new domain. You can imagine this being as the phone book of the Internet. Its primary function is to provide translation or resolution of hostnames to IP addresses.

It is much easier for you to memorize the domain name of a service (e.g. https://duckduckgo.com) than one of its corresponding IP addresses (e.g. 23.21.193.169). Typing the IP address in the URL bar and submitting would still take you to the site, but doing that for every website you are using is not very convenient. Instead, your computer relies on DNS servers to automatically do the mapping for you. To make requests even faster, it uses caching to store mappings for easier future reference.

The role of DNS is more predominant in distributed computing for the reason that it maps domain names to the IP address of the server that is closest to the client requesting it. This means the same domain name can be mapped to different IP addresses at the same time, which is a key feature in providing a faster and more reliable response to users.

How DNS Works

DNS servers can be any of these 4 categories:

Recursive nameserver (DNS Resolver)
Root nameserver
Top-level Domain (TLD) nameservers
Authoritative nameservers

Let's assume a user wants to visit https://mozilla.org and types the URL in the bar.

The computer searches for the associated IP address in the local DNS cache to see if this site has been recently retrieved. If it is found, the process ends here and the IP address gets returned.
If not found in the local cache, the computer continues to ask the DNS resolver from the Internet Service Provider (ISP) which has its own cache. Many customers of the ISP are likely using the same resolver, so popular services and domains will probably be cached. It looks for the mappings in the resolver's cache as well. If it's found, the process ends here and the IP address gets returned. Otherwise, it continues to the next stage.
The DNS resolver queries the root nameservers, which don't know the IP address but help direct the queries to the servers that know where to find it. These are responsible for knowing the IP addresses of the servers for each top-level domain (TLD). They look at the TLD of the domain name, which in our case is the .org in mozilla.org. Each TLD has its own set of nameservers. Then, it forwards our query to the TLD nameserver responsible for .org domain names.
The TLD nameserver looks at the next part of the domain name, the second-level domain (Mozilla in this example), and it directs the query to the authoritative nameserver which is responsible for this particular domain. This is the final stop of the DNS servers, and it is responsible for all the details about a particular domain. It contains many types of records, which are sets of different kinds of information about the domain. In this example, we are only looking for the IP address of the web server, so we request the authoritative nameserver for that information.
The DNS resolver receives the info and stores in its local cache for future reference. Another customer wanting to navigate to https://mozilla.org is spared this lookup process because of caching. But, cached records have expiration dates and need to be replaced with new copies by the resolver to ensure up-to-date information.
The record is returned to the client by the resolver. The client stores the record in its own cache. It then retrieves the IP address from the record and passes it to the browser, so the browser can open a connection and make the request to the web server with the site information.

Note: In occasions where the query contains a subdomain (e.g. https://developer.mozilla.org), there will be an extra nameserver that gets added to the end of the sequence which is responsible for that subdomain (developer).

All this process is performed whenever someone wants to visit a website, and it is completed in a matter of milliseconds.

It is important to know that caching may cause some problems. If a certain website changes its IP address and the local cache is not updated, that site may not be accessible since its address has changed and the cached address is now outdated. Security issues may also arise due to caching. If a malware has infected a user's device and poisoned the local cache, it may change the entries of hostname to IP mappings. It may change the IP address of a certain site, so it points to the server of a malicious site instead of the actual server. Therefore, clearing DNS cache regularly and using some anti-malware software is necessary.

DNS over HTTPS (DoH)

As you saw from the above text on how DNS works, DNS queries pass through the DNS resolver, which is basically an ISP. The information being passed around is in plain text, which means anyone including the ISP and a potential attacker can view DNS queries and therefore where you want to navigate to. This can be used for surveillance, eavesdropping, or to manipulate actual data to make users visit malicious sites. This raises big security and privacy concerns.

In recent years, there is a movement to implement encrypted DNS with a protocol known as DNS over HTTPS (DoH). DoH protocol takes advantage of the HTTPS protocol to encrypt DNS queries. It is the similar concept behind encrypting HTTP requests. It provides more security and privacy to users as it encrypts DNS data between the client and the resolver. Widely used browsers like Firefox Browser have already added these features in their settings, and it's being implemented by more and more browsers.

Originally Posted on OpenGenus IQ

DEV Community: Dawit

How to Bypass Ad Blockers for Vercel Analytics in Nuxt

The Problem: Analytics Blocked by Ad Blockers

The Solution: Proxying Analytics with Nuxt Middleware

Create a Proxy Middleware

Inject the Analytics Script

Verify and Adjust

How to Register Custom Directives in Nuxt 3

TL;DR

In Detail

How about in Nuxt?

Using Nuxt Content: Working with Remote Markdown Files

Get Started

What is Nuxt?

What is Nuxt Content?

Setup

Basics

Remote Content

Learn More

The JavaScript Fetch API

Diving Deeper into fetch()

A Few More Examples

Read More

HTTP Requests in JavaScript

1. XMLHttpRequest (XHR)

Methods

xhr.open()

xhr.send()

xhr.setRequestHeader()

xhr.abort()

Properties

xhr.response

xhr.responseType

xhr.readyState

Events

xhr.onload

xhr.onerror

xhr.onprogress

Example

2. Fetch

Read More

The JavaScript Fullscreen API

Introduction

Events

CSS

A Detailed Example

Read More

How Deno differs from Node.js

Modules

Security

Other Features

HTTPS Basics

Outline

Drawbacks of HTTP

The Solution: HTTPS

HTTPS = HTTP + SSL

Limitations of HTTPS

References

HTTP Basics

Outline

Terminology

How actually are requests made?

1. Start Line

2. Headers

3. Body

A few more examples

HTTPS

References

Domain Name System (DNS) Basics

Outline

Introduction

How DNS Works

DNS over HTTPS (DoH)

Diving Deeper into `fetch()`