Skip to content
Language:en Author:Laborci Gergely
http

Web addresses and resources

Objectives

By the end of the lesson, you can break a URL into its parts, say which part is meant for whom (the browser, the server, or the application), and understand why a web address is not a "file path".

Why do we need web addresses?

The web has to answer one question reliably: where is the thing I am looking for, and how can I reach it? If every service answered this in its own way, the browser could not work in a general manner. The web address (URL) gives the answer in a single, standard structure, so the browser can approach any service in the same way.

The address of a course page

Let us look at one address of Kurzuspont:

https://kurzuspont.example:443/kurzusok/webprog?felev=2026-osz&szuro=web%20programozas#kovetelmenyek

The address identifies the target more and more precisely from left to right.

Part Example Role
Scheme https The way of access: which protocol the browser uses to approach the target.
Host kurzuspont.example Which service the browser turns to.
Port 443 Which network "door" of the service we enter through.
Path /kurzusok/webprog Which resource we request within the service.
Query ?felev=2026-osz&szuro=web%20programozas Additional parameters: filtering, searching, selection.
Fragment #kovetelmenyek A part of the received document; handled by the browser.
flowchart LR
    S["Scheme<br/>https"] --> H["Host<br/>kurzuspont.example"]
    H --> P["Port<br/>443"]
    P --> U["Path<br/>/kurzusok/webprog"]
    U --> Q["Query<br/>?felev=2026-osz"]
    Q --> F["Fragment<br/>#kovetelmenyek"]

The diagram shows the order of the parts, not that the browser would look them up at separate stations.

This breakdown can also be done by a program. In Node.js (the server-side runtime of JavaScript), the URL class gives the same standard breakdown as the browser:

const u = new URL("https://kurzuspont.example:443/kurzusok/webprog?felev=2026-osz&szuro=web%20programozas#kovetelmenyek");
console.log(u.protocol, u.hostname, JSON.stringify(u.port), u.pathname, u.search, u.hash);
console.log([...u.searchParams]);

Output (executed, Node 24):

https: kurzuspont.example "" /kurzusok/webprog ?felev=2026-osz&szuro=web%20programozas #kovetelmenyek
[ [ 'felev', '2026-osz' ], [ 'szuro', 'web programozas' ] ]

The port is empty because :443 is the default port of HTTPS, so according to the URL standard it can be omitted. The same is not true for :8443: a different port must be preserved. The default ports are 80 for HTTP and 443 for HTTPS.

Host, domain, and port

A domain name is a name that humans can remember. It is not the server itself, and it does not necessarily denote a single machine: several servers can stand behind one name. The connection between the name and the network address (IP address) is made by DNS (chapter 4). All you need to know here is that the name is not the same as the network address.

The port denotes which network service of the target machine we turn to. During development http://localhost:3000/ is common: localhost denotes your own machine, and 3000 the port of a locally running service.

Path, query, and fragment

The path denotes a resource within the service. It does not have to correspond to a real file or folder: application code can stand behind /kurzusok/webprog and produce the response from a database.

The query carries key–value pairs separated by &. The server interprets it together with the path to decide what it must return (for example only the courses of autumn 2026). Each service defines the meaning of its parameters itself.

The fragment starts with # and jumps to a point of the already received document. The fragment stays in the browser: it is not sent to the server in the request (the relevant MDN page says this too). That does not make it secret: the person who sees the full address, the history, and the recipient of a shared link can all see it.

Special characters: percent-encoding

In a URL, certain characters (space, &, ?, #, accented letters) carry meaning or cannot appear directly. We rewrite them with percent-encoding: a space becomes %20, and é becomes %C3%A9 according to its UTF-8 (Unicode Transformation Format) bytes. The purpose of the encoding is that text inside the parameters should not get mixed up with the characters that mark the URL's structure:

console.log(encodeURIComponent("webprogramozás & adatbázis"));
webprogramoz%C3%A1s%20%26%20adatb%C3%A1zis

The encoded %26 is the sign of the & inside the data, so it does not start a new parameter. Browsers often show the address decoded, in a readable form, in the address bar, but the encoded form travels on the network.

Relative references

Not every link is a full address. On a page, the browser interprets the link ../adatbazisok?x=1 relative to the address of the current page:

console.log(new URL("../adatbazisok?x=1", "https://kurzuspont.example/kurzusok/webprog").href);
https://kurzuspont.example/adatbazisok?x=1

We use this for links within a site: the addresses do not depend on the concrete domain, so the site can be moved.

URL and resource

A URL is the identifier and access guide of a resource, not the resource itself. The same address can return different content at different times (the number of enrolled students changes). A resource can be an HTML document, an image, data, or the result of an application operation. A visible page can be assembled from parts fetched from several URLs.

The URI (Uniform Resource Identifier) is a broader identifier concept; the URL is the kind of it that also gives the means of access. In everyday work we say URL.

Worked example: the addresses of Kurzuspont

Address What does it request?
https://kurzuspont.example/ The home page
https://kurzuspont.example/kurzusok The list of courses
https://kurzuspont.example/kurzusok/webprog The page of one specific course
https://kurzuspont.example/kurzusok?felev=2026-osz A filtered version of the list
https://kurzuspont.example/kurzusok/webprog#kovetelmenyek The same page, jumping to the requirements section

The last two addresses point to the same path, but in different ways: the query is for the server (we ask for different content), the fragment is for the browser (the same content, read at a different point). This difference will also matter later for caching and security.

Common misconceptions

Statement Clarification
"The domain name is the server itself." The name identifies a service; it can lead to several network endpoints.
"The path is surely a folder on the server." The application can interpret it as any logical resource.
"The fragment is secret because it does not reach the server." It is visible in the address and can be shared.
"The port only exists during local development." It exists for production services too; we just do not write out the default port.
"The query safely carries confidential data." It can end up in logs, history, and sharing.

In brief

  • A URL consists of the scheme, host, port, path, query, and fragment.
  • The fragment belongs to the browser, the rest is part of the request.
  • The path is a logical resource, not necessarily a file.
  • Special characters are written with percent-encoding in a URL.
  • Secrets must not be put in a URL.

Review questions

  1. Break into parts: https://kurzuspont.example:8443/kurzusok?felev=2026-osz#lista!
  2. Which part does the browser not send to the server?
  3. Why do we need to encode the & sign in the value of a search term?
  4. Why is it dangerous to put a password into the query part of a URL?

Learning resources

Prerequisites (1)

  • client–server model

Teaches (1)

  • URL