Forem: Archit Sharma

Media types (MIME types) in HTTP explained

Archit Sharma — Fri, 31 Oct 2025 15:56:10 +0000

Media types (formerly known as a MIME types) is a standard way to describe the type and format of data being sent or received over the Internet.
MIME types are defined and standardized in IETF's RFC 6838.
MIME (Multipurpose Internet Mail Extensions) it was originally defined for email attachments but later adopted by HTTP and many other protocols.

Example, when a web server sends a response:

HTTP/1.1 200 OK
Content-Type: text/html

<html>
  <h1>Hello, World!</h1>
</html>

The header Content-Type: text/html tells the browser that the body contains HTML, so it should render it as a web page.

Structure of a Media Type

A MIME/Media type consists of just two parts: a type and a subtype, separated by a slash (/)

type/subtype

The type is the general data category (e.g., video or text), while the subtype is the specific format within that category (e.g., html or plain for the text MIME type).

For a complete list of all official MIME types, see the IANA (Internet Assigned Numbers Authority) Media Types registry.

Optional parameters

Sometimes, a media type includes optional parameter after a semicolon (;)
Syntax:

type/subtype;parameter=value

For example: text/plain;charset=UTF-8

MIME types are traditionally written in lowercase, but they are case-insensitive. However, their parameter values can be case-sensitive.

MIME types are divided into two major classes based on the structure of their content:

1. Discrete types

Discrete types represent a single file, such as a single text or music file, or a single video. It's commonly used in HTTP bodies for typical web content (HTML, JSON, images, etc.). For example:

text/plain - plain text
image/jpeg - a JPEG image
application/json - a JSON document
video/mp4 - an MP4 video file

For text documents without a specific subtype, text/plain is used. For any unrecognized binary file, application/octet-stream is used.

2. Multipart types

Multipart types represent a collection of multiple discrete parts, each with its own headers and MIME type, combined in a single body.
For example:

multipart/form-data - used in HTML forms (like file uploads)
multipart/mixed - contains different types of content together
multipart/alternative - multiple representations of the same content (like HTML + plain text emails)

MIME sniffing

MIME sniffing is the process by which a web browser tries to determine the actual content type of a resource by inspecting its bytes
If a MIME type is missing or seems incorrect, browsers may perform MIME sniffing.

Since MIME sniffing is implemented differently in each browser and can be triggered under various circumstances, it introduces security risks. A malicious file could be misinterpreted as a safe, executable type. To mitigate this, servers can explicitly prevent sniffing by using the X-Content-Type-Options header.

HTTP Request and Response explained

Archit Sharma — Thu, 30 Oct 2025 11:45:01 +0000

In this article we will take a look at general overview of the HTTP messages.

NOTE: The HTTP message formats, methods, and semantics described in this article are based on the official IETF specifications defined in RFC 9110

HTTP is a stateless protocol where clients and servers exchange HTTP messages through a simple request-response cycle. A client initiates by sending a request (containing a method, target, headers, and optional content). A server replies with a response (containing a status code, headers, and optional content).

You don't need to build HTTP messages by hand. Tools like your browser or a web server are programmed to create them correctly. Developers just use APIs and configuration files to control what those messages contain.

While each HTTP version has its own message format, this article uses HTTP/1.1 messages for readability for all HTTP messages.

HTTP Request

An HTTP request message has following four components mentioned below:

A Request-line: <Method> <Request-Target> <Protocol-Version>
Header (General|Request|Entity) fields followed by CRLF
An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
Optionally a message-body

Let's explore each component of an HTTP request message in detail:

Request Line

The start-line in HTTP/1.x requests is called a "request-line" and is made of three parts:

1. Method

The request method (like GET or POST) specifies the client's intention for the request and what a successful response should accomplish.

The following table lists all the supported methods in HTTP:

Method Name	Description
GET	The GET method is used to retrieve information from the given server using a given URI.
HEAD	Same as GET, but it transfers the status line and the header section only.
POST	A POST request is used to send data to the server
PUT	PUT updates a resource by replacing all of its data with the new content sent in the request.
DELETE	Removes the target resource entirely.
CONNECT	Sets up a direct network tunnel to a remote server, usually through a proxy. This is primarily used to establish HTTPS connections through a proxy.
OPTIONS	Retrieves the HTTP methods and other communication options that the server supports for the target resource.
TRACE	Performs a loop-back diagnostic test. The server echoes the received request message back to the client, allowing inspection of any modifications made by intermediaries along the path.

2. Request target

Request target is used to identify which resource the client wants to interact with. The format of the request target (usually a URL) is determined by both the HTTP method being requested and whether the request is to a proxy

Following are the most commonly used forms of targets:

Method	Description
Origin form	The most common form of Request target, consisting of the path and optional query string: `origin-form = absolute-path [ "?" query ]` When contacting a server directly, clients must send only the path and query from the full URL. The domain is sent separately in the `Host` header. Example: For `http://www.example.org/where?q=now`, the request is: `GET /where?q=now HTTP/1.1`
Absolute form	The absolute-form is used when sending requests through a proxy. Instead of just the path, the client sends the complete URL as the request target. Example: `GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1`
Authority form	The authority form is the host and port separated by a colon (:). It is only used with the `CONNECT` method when setting up an HTTP tunnel. Example: `CONNECT www.example.com:80 HTTP/1.1`
Asterisk form	The asterisk-form uses just * and is used only with the `OPTIONS` method to ask about the server’s overall capabilities, not any specific resource. Example: `OPTIONS * HTTP/1.1`

3. Protocol Version

Protocol Version in a request is a declaration made by the client indicating both the syntax format of the message being sent and the highest level of protocol features the client can understand for future communication from the server.

Learn more about HTTP Versions

Request Header Fields

Request Header fields allow the client to pass additional information (metadata) about the request, and about the client itself, to the server.

The format of an HTTP/1.x header is straightforward: a case-insensitive name, a colon (:), and then a value. The entire header field must fit on a single line.

Example of Request Header:

Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49

NOTE: A detailed explanation of HTTP headers and their various types will be covered in upcoming articles.

Request body

The Request Body (content) is the part of an HTTP request that carries data from the client to the server. Only PATCH, POST, and PUT requests have a body.
The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field.

HTTP Response

An HTTP response message has following four components:

A Status-line: <HTTP-Version> <Status-Code> <Reason-Phrase>
Header (General|Response|Entity) fields
An empty line indicating the end of the header fields
Optionally a message-body

Status line

The first response line is the status-line, containing: protocol version, status code, and an optional reason phrase, each separated by spaces.
Example:

HTTP/1.1 200 OK

Detailed breakdown:

1. HTTP Version

HTTP Version or Protocol Version in a HTTP Response tells the client which set of protocol rules the server follows.
The "HTTP" in the HTTP-version is case-sensitive and must be written in uppercase. HTTP uses a major.minor numbering system, defined in RFC 9112.

2. Status Code

A status code is a three-digit number (from 100 to 599) that describes the result of an HTTP request. Only the first digit of a status code defines its class, while the last two digits have no categorization role.
There are five possible class values:

Status Code	Description
1xx (Informational)	It means the request was received and the process is continuing.
2xx (Success)	The request was successfully received, understood, and accepted
3xx (Redirection)	Further action needs to be taken in order to complete the request
4xx (Client Error)	The request contains bad syntax or cannot be fulfilled
5xx (Server Error)	The server failed to fulfill an apparently valid request

A list of all the status codes can be found in RFC 9110.

3. Reason phrase

Following the status code is an optional reason phrase, a human-readable description like Created, which explains the outcome. Its optional nature is sometimes shown with parentheses.

Response headers

Response headers are metadata sent with a response. In HTTP/1.x, each is a case-insensitive string followed by a colon (:) and a value, whose format is header-specific.

NOTE: A detailed explanation of HTTP headers and their various types will be covered in upcoming articles.

Response body

A response body is included in most messages. For successful GET requests, it contains the requested resource. For errors, it typically provides a description of the error and indicates whether it is permanent or temporary.

How an HTTP Session Works

Archit Sharma — Sun, 26 Oct 2025 17:51:25 +0000

In this article, we will discuss How an HTTP Session Works.
HTTP consist of three phases:

Connection Phase - The client initiates a TCP connection (or another designated transport protocol) to the server.
Request Phase - The client sends an HTTP request and waits for the HTTP response from the server.
Response Phase - The server processes the request and sends an HTTP response to the client.

NOTE: For a comparison of how connections are handled in different HTTP versions, see my article on HTTP Version History.

The initial connection phase

It is always the client which establishes the connection.
From HTTP/1.0 through HTTP/2, TCP was used to initiate connections in the transport layer. This changed with HTTP/3, which replaced TCP with QUIC over UDP.

TCP uses default port 80 for an HTTP server on a computer. Underneath, TCP goes through a process known as the three-way handshake to establish a connection. You can learn more about this process in RFC 793, Section 3.4.

Client HTTP Request

Now user-agent (typically a web browser, but can be anything else) can send the HTTP Request.
HTTP request consists of text directives (human-readable text commands), separated by CRLF (special character sequence that means end of the line) divided into three blocks:

The first line consists of a request method, followed by the path of the document, and the HTTP protocol version.
The second line consists of HTTP Headers, which are key-value pairs of text information that are sent with every HTTP request and response.
Third block is an optional data block, which is mainly used by the POST method.

Here is an example of HTTP Request:

GET / HTTP/1.1
Host: example.com
Accept-Language: fr

Request Methods:

Request Methods indicate the purpose of the request and what is expected if the request is successful. These request methods are commonly referred to as HTTP verbs, though they can also be nouns. Most common methods are GET and POST.

NOTE: We will explore HTTP methods in more detail in upcoming articles.

Server HTTP Response

The web server processes the HTTP request from the client and returns a response.
Just like an HTTP request, an HTTP response also consists of text directives, separated by CRLF, and is divided into three blocks:

The first line, known as the status line, consists of an acknowledgment of the HTTP version used, followed by a response status code and a brief message.
The second line contains HTTP headers, which give the client information about the data being sent. These headers form a block that ends with an empty line.
The third line is a data block, which contains the optional data.

Example of HTTP Response:

HTTP/1.1 200 OK
Date: Mon, 27 Oct 2025 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Sat, 25 Oct 2025 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

HTTP status codes:

HTTP status codes indicate whether a specific HTTP request has been successfully completed. Responses are categorized into five types: informational responses, successful responses, redirects, client errors, and server errors.

NOTE: We will explore HTTP status codes in more detail in upcoming articles.

The History of HTTP

Archit Sharma — Sat, 25 Oct 2025 06:06:47 +0000

HTTP (HyperText Transfer Protocol) is a protocol used for fetching resources such as HTML documents. Its primary function is to enable a conversation between a client (like a web browser) and a server (where a website is hosted).

In this article, we will discuss how the World Wide Web was invented and how HTTP evolved from HTTP/0.9 to modern-day HTTP/3.

How the World Wide Web Was Invented

Tim Berners-Lee wrote a proposal to build a hypertext system over the internet in 1989, while working at CERN.

It had four fundamental pieces, all completed by the end of 1990:

HyperText Markup Language (HTML) - provide a textual format for hypertext documents.
HyperText Transfer Protocol (HTTP) - protocol to exchange these documents.
First Web Browser (WorldWideWeb) - a client to display these documents.
Early version of httpd - a server to give access to the document.

On August 6, 1991, Tim Berners-Lee posted the first ever web page. This date is now considered the official start of the World Wide Web as a public project.
You can still visit a restored version of it here: http://info.cern.ch/hypertext/WWW/TheProject.html

The HTTP protocol used in those early days was later named HTTP/0.9 and is sometimes called the one-line protocol.

HTTP/0.9

The first version of HTTP had no version number, but later it was called HTTP/0.9. It was a very simple protocol.
The Request message consisted of a single line, which began with the method (only GET was available) followed by the path to the resource. This is why its also known as the one-line protocol.

GET /my-page.html

The Response message only consisted of the file itself.

<html>
  An text-only web page
</html>

There were no HTTP headers and no status or error codes.

HTTP/1.0

Despite its limitations, HTTP/0.9 was rapidly enhanced by browsers and servers.
HTTP/1.0 introduced numerous improvements:

The version number, such as HTTP/1.0, was included directly in the request line.
By introducing HTTP headers for both requests and responses, the protocol gained the ability to carry metadata, making it very flexible and extensible.
Support for non-HTML content (like images, PDFs etc.) was made possible through the implementation of the Content-Type header.
A status code line was sent at the beginning of a response.

A typical request and response looked like this:

GET /page.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

HTTP/1.0 200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
Hello World
  <IMG SRC="/image.gif">
</HTML>

In the early days of the web (1991-1995), there was no official rulebook for new features. Developers would invent a new feature and wait to see if other browser and server developers adopted it. If others started using it, it became a de facto standard. If not, it would be abandoned.
To solve this issue, an informational document describing common practices was published in November 1996. This was known as RFC 1945 and defined HTTP/1.0.

HTTP/1.1

Just a few months after HTTP/1.0 (RFC 1945), the first standardized version of HTTP, HTTP/1.1, was published in early 1997.
HTTP/1.1 introduced major improvements:

Persistent Connections - a single TCP connection could be kept open and reused for multiple requests and responses, eliminating the significant overhead of repeatedly establishing connections.
Pipelining - a browser could send several requests back-to-back without waiting for the first response to arrive, reducing the delay (latency) in communication. (In practice, pipelining was difficult to implement correctly and was eventually superseded in HTTP/2).
Additional Cache Headers - It introduced much more powerful headers for controlling caches (both browser caches and proxy caches).
Chunked Responses - The server could send the response in pieces, or "chunks." It would send a Transfer-Encoding: chunked header and then stream the data in smaller parts, each with its own size indicator.
HOST Header - introduced the ability to host different domains from the same IP address.
Content Negotiation - a client and a server could now agree on which content to exchange.

HTTP/1.1 was first published as RFC 2068 (The Proposed Standard) in January 1997.
HTTP/1.1 protocol was refined over two revisions, RFC 2616 published in June 1999 and RFC 7230-RFC 7235 published in June 2014 before the release of HTTP/2.
The HTTP/1.1 standard (RFC 2616) remained stable for over 15 years.
In 2022, HTTP/1.1 was updated again with RFC 9110 & RFC 9112.

In 1994, Netscape created SSL (later standardized as TLS) to encrypt web traffic. This was initially for e-commerce security, but became essential for the entire web as it evolved from an academic network to a space where privacy and data protection were critical for all websites and applications.

The web was originally meant to be editable. WebDAV (with CalDAV/CardDAV) enabled this but required special server support.

REST (2000) became more popular by using standard HTTP methods on specific URLs, allowing any website to create its own API without browser updates. The trade-off was that each REST API was custom, unlike WebDAV's standardization.

HTTP and web security (same-origin policy) were developed separately. Over time, new HTTP headers were created to safely lift some security restrictions:

CORS - Allows controlled cross-origin requests
Content Security Policy (CSP) - Prevents certain types of attacks
Other headers like Do Not Track (DNT), X-Frame-Options, etc., were added for specific security and privacy needs

HTTP/2

Over the years, websites started using more videos, images, and complex scripts to make pages interactive. Websites sent more data and made more requests, which overwhelmed HTTP/1.1 and made it inefficient.
To address this issue, Google developed and deployed SPDY, an experimental protocol, in the early 2010s. Developers widely adopted Google's SPDY protocol because it made websites faster and more efficient. Its success directly led to the creation of the official HTTP/2 standard.

Here are the main ways HTTP/2 differs from HTTP/1.1:

Binary Protocol - HTTP/2 used binary instead of plain text which is much harder for humans to read, but computers can process binary data much faster and more efficiently.
Multiplexing - Parallel requests can be made over the same TCP connection.
Header Compression - It uses a smart technique (HPACK) that eliminates sending duplicate header fields, drastically reducing the amount of data that needs to be sent.

HTTP/2 standardized in May 2015 with RFC 7540 and RFC 7541.
HTTP/2 saw a rapid adoption because it didn't require changes to websites and applications. To use it, only an up-to-date server that communicated with a recent browser was necessary.

HTTP's extensibility still drives new features, notably these 2016 extensions:

Alt-Svc (Alternative Service) - enables smarter CDN caching because the browser can seamlessly switch to the faster location without changing the original resource's identity.
Cookie Security Prefixes - It guarantees that a "secure" cookie is truly secure from the moment it's created.
Client Hints - allows your browser to proactively tell the server about its capabilities and constraints.

HTTP/3

While HTTP/3 keeps the request/response semantics of HTTP/1.1 and HTTP/2, it uses QUIC instead of TCP for the underlying connection.
As of October 2025, HTTP/3 is used by 35.9% of all the websites.

Some major improvements of HTTP/3:

Eliminates Head-of-Line Blocking - QUIC handles streams independently. If a packet is lost, only that specific stream is paused while others continue uninterrupted.
Faster Connection Establishment - QUIC builds encryption directly into the protocol, combining the TCP handshake and TLS encryption into a single step, significantly reducing initial connection latency.

HTTP/3 standardized in June 2022 with RFC 9114, RFC 9204 and RFC 9250

Styling the Lynx project

Archit Sharma — Wed, 12 Mar 2025 08:04:18 +0000

In this article, we will dive into the world of styling in Lynx.
Styling a Lynx app shares similarities with styling web apps, but it also introduces some key differences.

1) Lynx-Specific Properties (`-x-` prefixed properties)

Lynx introduces properties that start with -x- to make it easier to style the design. These properties are specific to Lynx and are not part of standard CSS.

Example, The -x-handle-color property is used specify the color of the floating marker when copying text.

.text1::selection {
  -x-handle-color: blue;
}

Refer to the official docs for all the styling properties

2) Inline Styles and Selectors S

In Lynx, inline styles are used in a way very similar to React's inline styling, where styles are passed as an object.
Example:

<view
      style={{
        flexDirection: "column",
        marginTop: "50%",
        transform: "translate(-50%, -50%)",
        marginLeft: "50%",
        width: "150px",
        height: "150px",
      }}
    >
    </view>

3) Nesting Syntax:

Native CSS does not support nesting but Lynx supports nesting syntax similar to Sass or PostCSS.
Example:

.a {
  background: red;
  &-b {
    border-radius: 30px;
  }
}

/* equals */

.a {
  background: red;
}

.a-b {
  border-radius: 30px;
}

Now that you know the basics, you can start exploring these APIs, which illustrate different Styling components in Lynx.

Now that we understand how to style the Lynx project, we'll explore the Layout in the next article.

Follow for more!

Understanding Lynx Core Elements

Archit Sharma — Sun, 09 Mar 2025 08:19:08 +0000

In this article, we will explore the core elements in Lynx. When we use React to create web user interfaces, we often utilize HTML tags such as <div>, <span>, and <p>.

Here is an example React component:

function example() {
    return (
        <div>
            <p>Hello World</p>
        </div>
    );
}

It is important to note that the elements we write for the web are specific to the browser's understanding of HTML. When working with Lynx, these elements will not work because Lynx does not incorporate the concept of the DOM (Document Object Model).

Element tags

Lynx uses element tags that are similar to HTML elements. However, Lynx employs some unique element tags such as <view>, <text>, and <image> to display different types of content. Here is an example of how to display "Hello World" text:

<text>Hello World</text>

Just like HTML elements, Lynx element tags also support attributes. These attributes can be used by adding attribute names and values within the element tag.
In this example, style is the attribute name, and background:green is the attribute value.

<text style="background:green;">Hello World</text>

Learn more about attributes, refer to the API Reference.

Built-in Elements

The Lynx Engine includes built-in elements by default.

View

The view is fundamental building block for user interfaces in Android and iOS development.
A <view> is a small rectangular element on the screen that can display text, images, or user input.

<view style="background:red;">
  <text>Hello World!</text>
</view>

Image

The <image> element is used to display images.

<image auto-size style="width:100px;" src="./assets/example.png" />

Check out more built-in Lynx elements by referring to the Built-in Elements Documentation.

Native Rendering of Elements

At runtime, Lynx generates the corresponding iOS and Android component, or HTML elements on the Web.
Here is a diagram from the official docs:

Check out the documentation to learn more about native rendering.

In the next article, we will learn about using CSS for styling Lynx pages.

Follow for updates!

Try out the new framework to build native applications!

Archit Sharma — Fri, 07 Mar 2025 07:49:51 +0000

Create Lynx project

Archit Sharma ・ Mar 7

#react #webdev #reactnative #javascript

Create Lynx project

Archit Sharma — Fri, 07 Mar 2025 07:48:44 +0000

In this article, let's create our very first Lynx project. To begin, let's first set up our development environment.
For Lynx, we need two things installed:

Node.js
VS Code (or any text editor of your choice)

Now that we have our development environment ready, let's proceed.
Open your command prompt in the location where you want to create your project directory and type the following prompt:

npm create rspeedy@latest

Type a project name, or simply press Tab to use the default project name.
Select a language: TypeScript or JavaScript. I will choose TypeScript, as it is recommended.
Select additional tools. I will choose Biome, but you can select any.

This prompt will create a folder with your project name.

Now, navigate to your project directory and install the NPM dependencies using package manager.

npm install

Start the Development Server

npm run dev

NOTE: In Windows Currently, you may get an error like the one below. This might be fixed in the future, but for now, let's manually fix it.

Steps to fix this error:

1) Install the following npm package

npm i @lynx-js/react-rsbuild-plugin-canary

2) Go to lynx.config.ts file and update this import from:

import { pluginReactLynx } from '@lynx-js/react-rsbuild-plugin'

To this:

import { pluginReactLynx } from '@lynx-js/react-rsbuild-plugin-canary'

Now start the Development Server again

npm run dev

You might encounter another error now. To fix it, do the following:

Goto node_modules/@lynx-js/tasm/index.js file and search for the let encode = encode_napi; and replace it with let encode = getEncodeMode();
Now, run the development server again, and it should work.

The next step is to install the Lynx Explorer app on your iOS or Android device to view the UI.

Refer to the official documentation to learn how to install Lynx Explorer.

Once you installed Lynx Explorer app, you can scan the QR code using the App from the terminal and it will display the live UI on Lynx Explorer

Now make a change and you will see the UI on your Lynx Explorer being updated automatically.

Now that we understand how to generate a new Lynx project using Rspeedy, we'll explore the project's directory structure in the next article.

Follow for more!

The best static site generators in 2024🚀🔥

Archit Sharma — Thu, 29 Aug 2024 09:09:05 +0000

We're all familiar with static site generators, so let's dive straight into the most loved ones of 2024. These generators have been tried, tested, and reviewed by the community, making them top choices for developers.

1. Next.js

Next.js is currently the leading framework for ReactJS development. It's far more than a simple static site generator; it provides robust features like server-side rendering, built-in API routes, and extensive customization options.

It’s particularly suited for React-based projects that require a high level of flexibility and customization, supported by a large and active community along with a vast array of resources.

2. Nuxt.js

Nuxt.js, built on top of Vue.js, is known for its intuitive syntax and user-friendly approach, making it an excellent choice for developers looking to quickly set up and build web applications. It offers a range of out-of-the-box features such as server-side rendering, static site generation, and routing, which significantly speed up the development process while reducing the need for extensive configuration.

3. Astro

Astro is a relatively new static site generator that has quickly gained popularity. It comes fully equipped with everything needed to build content-driven websites, including blogs, personal portfolios, marketing sites, e-commerce platforms, and more. Astro stands out for its strengths in static site generation, component-based architecture, and user-friendly experience, making it an excellent choice for content-focused projects.

4. Hugo

Hugo is a fast, lightweight, and flexible static site generator, ideal for content-centric websites with straightforward templates and minimal dynamic elements. However, being Go-based and more verbose, Hugo can have a steeper learning curve and may require more effort to adapt and master.

5. Eleventy

Eleventy is an open-source static site generator built with JavaScript. Although relatively new, it has quickly gained popularity for its simplicity. Unlike typical JavaScript frameworks, Eleventy doesn’t include any unnecessary boilerplate code, providing a clean and lightweight approach. If you’re looking for a highly flexible and customizable solution with a strong emphasis on JavaScript, Eleventy is an excellent choice.

6. Gatsby

Gatsby is an open-source ReactJS framework designed for creating fast and secure static sites using data from multiple platforms. Its standout feature is its unified data layer, which seamlessly integrates data from various sources and incorporates it into your site's markup. If your goal is to build highly efficient static websites with access to a vast plugin ecosystem, Gatsby is a great choice.

If you found this article helpful, please consider following or sharing it so that others can benefit too!

Thank you!

Securing My First Internship with Open Source

Archit Sharma — Tue, 28 May 2024 21:17:09 +0000

Hey👋, I am Archit Sharma, a student and SDE based in India. In this blog, I aim to share my experience and journey of obtaining my first internship through open source contributions.

How did it all begin?

It all started back in 2023 when I was confused about what I was doing. I was learning different tech stacks but wasn't applying them anywhere. One night, I was looking through the LFX mentorship page and found a project called Meshery, which is under Layer5. Even though I didn't have all the required tech stacks, I still applied.

A few days later, I received a DM from the founder of Layer5, asking me to participate in the community and projects. He also gave me a brief introduction to the community and its projects.

And that is how I kickstarted my journey in open source.

Joining the Community

I joined the Layer5 Slack and introduced myself in the #newcomers channel, where I received advice to join the website meeting held every Monday. Taking that advice, I attended the website meeting. At first, I was a bit shy, but then I introduced myself during the meeting. Additionally, I received my very first issue to work on during the same meeting. It was a simple task—just adding an image to a React component.

From that day onward, I never looked back and continued making contributions to the project. After six months of contributing, I was offered a six-month internship with Layer5.

Advice for New Open Source Contributors

Consistency is key, be consistent in solving the project's problems
Ask your questions, but don't overly rely on or disturb the maintainers, as they might end up solving the issue themselves.
Things may seem overwhelming at first, but with patience, everything will eventually start to make sense.

Conclusion

Besides all of this, Layer5 is an awesome organization for networking and learning new things. In my opinion, it’s the most beginner-friendly organization, and I advise all open source beginners to give it a try.

You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something - your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life. - Steve Jobs

Forem: Archit Sharma

Media types (MIME types) in HTTP explained

Structure of a Media Type

Optional parameters

MIME sniffing

HTTP Request and Response explained

HTTP Request

Request Line

Request Header Fields

Request body

HTTP Response

Status line

Response headers

Response body

How an HTTP Session Works

The initial connection phase

Client HTTP Request

Request Methods:

Server HTTP Response

HTTP status codes:

The History of HTTP

How the World Wide Web Was Invented

HTTP/0.9

HTTP/1.0

HTTP/1.1

HTTP/2

HTTP/3

Styling the Lynx project

1) Lynx-Specific Properties (-x- prefixed properties)

2) Inline Styles and Selectors S

3) Nesting Syntax:

Understanding Lynx Core Elements

Element tags

Built-in Elements

View

Image

Native Rendering of Elements

Try out the new framework to build native applications!

Create Lynx project

Archit Sharma ・ Mar 7

Create Lynx project

Steps to fix this error:

The best static site generators in 2024🚀🔥

1. Next.js

2. Nuxt.js

3. Astro

4. Hugo

5. Eleventy

6. Gatsby

Top 10 Popular Terraform Interview Questions

Questions List

What are the key features of Terraform?

What are the most useful Terraform commands?

What is Terraform init?

What do you understand by terraform backend?

What are modules in Terraform?

What is a Private Module Registry?

How to Store Sensitive Data in Terraform?

Explain State File Locking?

Top 10 Popular Kubernetes Interview Questions

Questions List

What is the Difference b/w Docker and Kubernetes?

What are the main components of Kubernetes architecture?

What are the main differences between the Docker Swarm and Kubernetes?

What is the differences between the Docker container and a Kubernetes pod?

What is a namespace in Kubernetes?

What is the role of Kube-proxy?

What are different types of services within Kubernetes?

What is the difference between NodePort and LoadBalencer type service?

What is the role of Kubelet?

What are your Day to Day activities on Kubernetes?

Securing My First Internship with Open Source

How did it all begin?

Joining the Community

Advice for New Open Source Contributors

Conclusion

1) Lynx-Specific Properties (`-x-` prefixed properties)