What happens when you visit a URL?

The journey of a click

Every time you type a URL or click a link, a complex sequence of events happens in milliseconds. Understanding this journey is the foundation of web development: because every feature you build in Rails is part of this cycle.

Let's trace what happens when you visit https://example.com/courses.

---

Step 1: the browser parses the URL

The browser breaks the URL into parts:

https://example.com/courses?sort=newest
│       │            │       │
Scheme  Host         Path    Query String

Part	Value	Purpose
Scheme	https	Protocol to use (HTTP or HTTPS)
Host	example.com	Which server to contact
Path	/courses	Which resource on the server
Query string	sort=newest	Additional parameters

The browser now knows what it wants and where to find it.

---

Step 2: DNS lookup: finding the address

Domain names like example.com are for humans. Computers need IP addresses (like 23.215.0.136, one of the addresses example.com resolved to in 2025). The Domain Name System (DNS) translates between the two.

flowchart LR
  B["Browser: where is example.com?"] --> L["Local cache"] --> R["Router cache"] --> I["ISP DNS"] --> RT["Root DNS"] --> C[".com DNS"] --> E["example.com DNS"] --> A["Answer: 23.215.0.136"]

This is like looking up a phone number in a contact list:

• First, check if you already know it (cache)
• If not, ask someone who might know (DNS servers)
• Eventually, get the number (IP address)

In Rails development, localhost resolves to 127.0.0.1: your own machine. No DNS lookup needed.

---

Step 3: TCP connection: establishing contact

Now the browser knows the IP address. It establishes a TCP connection: a reliable two-way communication channel.

sequenceDiagram
  participant B as Browser
  participant S as Server
  B->>S: SYN ("Can we talk?")
  S-->>B: SYN-ACK ("Yes, go ahead")
  B->>S: ACK ("Great, starting")
  Note over B,S: Connection established!

This is the three-way handshake: like a phone ringing, being picked up, and the caller saying "hello."

For HTTPS, an additional TLS handshake happens to encrypt the connection.

---

Step 4: HTTP request: asking for the page

With the connection established, the browser sends an HTTP request:

GET /courses?sort=newest HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
Accept: text/html
Accept-Language: en-US,en;q=0.9
Cookie: session_id=abc123

This is a structured message that says:

• GET: I want to retrieve (not create or modify)
• /courses?sort=newest: This specific resource
• Host: example.com: On this server
• Accept: text/html: I want HTML back
• Cookie: Here's my session identifier

---

Step 5: server processing: Rails takes over

The server receives the request and passes it to your Rails application:

flowchart TB
  R["HTTP request"] --> W["Nginx / Puma (web server)"] --> M["Rails middleware stack"] --> RT["Router (config/routes.rb)"] --> C["Controller action"] --> MO["Model (database query)"] --> V["View (HTML template)"] --> RS["HTTP response"]

In Rails terms:

# In this app, the course list lives at /catalog/roadmap
# config/routes.rb
namespace :catalog do
  get "roadmap", to: "courses#index", as: :roadmap
end

# app/controllers/catalog/courses_controller.rb
def index
  result = Catalog::ListCoursesQuery.call(authenticated: current_user.present?)
  @courses_by_level = result.courses_by_level
  # ...
end

# app/views/catalog/courses/index.html.erb
# Generates HTML using @courses_by_level

---

Step 6: HTTP response: the answer

The server sends back an HTTP response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 12847
Set-Cookie: session_id=abc123; path=/; HttpOnly

<!DOCTYPE html>
<html>
  <head><title>Courses</title></head>
  <body>
    <h1>All Courses</h1>
    ...
  </body>
</html>

This response contains:

• Status code (200 OK): The request succeeded
• Headers: Metadata about the response
• Body: The actual content (HTML in this case)

---

Step 7: browser rendering: showing the page

The browser receives the HTML and:

1. Parses the HTML into a DOM tree
2. Fetches additional resources (CSS, JavaScript, images)
3. Applies CSS styles
4. Executes JavaScript
5. Paints the final result on screen

Each additional resource (CSS file, image, JS bundle) triggers its own mini request-response cycle.

---

The complete picture

sequenceDiagram
  participant B as Browser
  participant D as DNS
  participant S as Server (Rails)
  B->>B: 1. Parse URL
  B->>D: 2. DNS lookup
  D-->>B: IP address
  B->>S: 3. TCP handshake
  S-->>B: Connection OK
  B->>S: 4. HTTP request
  S->>S: 5. Route → Controller → Model → View
  S-->>B: 6. HTTP response
  B->>B: 7. Render

All of this happens in under a second for a well-built application.

---

Why this matters for Rails developers

Every Rails concept maps to a part of this cycle:

Cycle Step	Rails Concept
URL parsing	routes.rb, path helpers
HTTP Request	params, request object
Server processing	Controllers, models, services
HTTP Response	render, redirect_to, status codes
Cookies/Sessions	session, cookies, authentication
Caching	Fragment caching, ETags, HTTP caching

Understanding the full cycle helps you debug issues, optimize performance, and build features that work with the web instead of against it.

---

Summary

Step	What Happens
1. URL parsing	Browser breaks URL into scheme, host, path, query
2. DNS lookup	Domain name → IP address
3. TCP handshake	Establish reliable connection
4. HTTP request	Browser asks for a resource
5. Server processing	Rails routes, processes, queries database
6. HTTP response	Server sends status code, headers, and body
7. Browser rendering	HTML → DOM → paint on screen