What HTTP and HTTPS are
HTTP is the agreement a browser and a server talk in: the browser sends a request, the server returns a response, and a three digit code says whether it worked. HTTPS is that same agreement travelling inside an encrypted layer, so nobody in the middle can read the content or change it.
- Lesson 6 of 12
- Beginner
- Free, no signup
The two ends of one conversation, and what crosses the bridge
The browser
It always starts. The server never calls first.
The server
It only answers, and between two requests it remembers nothing about you.
This bridge shows one round trip. An ordinary page repeats it dozens of times, once for the page itself and again for every image, font and script.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
What actually gets exchanged when you open an address?
The browser builds and sends a request, and the server returns a response. HTTP is the name of the agreement that fixes the shape of both: the request says what it wants and from where, the response says how it went and what the body is.
Each one has a first line, then a set of headers, then a body. The headers are where almost everything is hidden: the browser language, whether the content is compressed, how long the response may be cached, what the server calls itself. When a page behaves strangely the answer is usually not in the body, it is in the headers.
One property the name hides: HTTP has no memory. Every request is independent as far as the server is concerned, and by itself the server does not know this is the same person who came a second ago. What makes signing in possible is only one extra header that the browser sends again every time. Once you know that, half of the strange behaviour around staying signed in stops being strange.
Newer versions carry the same agreement over the wire more tidily and more compactly, and they do not change what a request and a response mean. The pages of this site answer over HTTP/2, and the content delivery network sitting in front of it announces in a separate header that HTTP/3 is also ready. For a reader that difference is invisible, and it should be.
How do you read a status code?
The first digit says almost everything and the rest is detail. Two hundred means it worked, three hundred means go somewhere else, four hundred means the request was at fault, five hundred means the server fell over on its own. That one sentence is enough in practice to know whose problem it is.
| Code | What it means | Who has to act |
|---|---|---|
200 | The response is ready and the body is what you asked for | Nobody |
301 | This address has moved somewhere else permanently | Anyone still linking the old address |
404 | The server is healthy and has no such address | The site owner, or whoever mistyped the address |
500 | The request was fine and the program on the server failed | Only the server owner |
Let us finish off a common misreading here: 404 means the page was not found, not that the site is broken. The server was perfectly healthy and was able to say with confidence that it has no such thing. The body is not necessarily empty either; the not found page on this site is a complete page with a menu and a search box, and its HTML is more than a hundred kilobytes. The code and the look of the page are two independent things.
And a trap we have paid for on this very server: the status code and the response body do not always arrive together. The layers in front of the application, meaning the web server and the content delivery network, are allowed to replace the body of an error response with a page of their own. The result is that your program sent a precise error message and the user saw a generic page. If you are ever debugging an error that exists in the server log and not in the browser, suspect this first.
The first digit, and the one code from each family worth knowing
-
nothing to do
Code 200: it worked
The response is ready and the body is what you asked for.
-
update the old link
Code 301: go elsewhere
A 301 says this address has moved permanently.
-
the server is healthy
Code 404: the request was at fault
A 404 means the server was able to say with confidence that it has no such address.
-
only the server owner
Code 500: the server fell over
A 500 means the request was fine and the program on the server failed.
These four families are not the only ones, and each family holds other codes too. These are the ones a site owner actually runs into.
What exactly does HTTPS secure?
Three things, no more. First, confidentiality: anyone sitting in the middle, from the operator to the owner of a public wifi, sees only which domain you talked to and how much data moved; not the exact page address and not the content. Second, integrity: if someone changes one byte on the way, the browser notices and drops the connection. Third, the identity of the domain: the browser makes sure the server answering really holds a certificate for that domain.
This is done with a certificate signed by an outside issuing authority, plus a short handshake at the start of the connection that builds the encryption key for that session. The certificate of this site can be looked at right now: it is issued by Google Trust Services, it is valid for rgb.ir and any of its subdomains, and it lives for ninety days. The short life is deliberate; a short lived certificate renews automatically, and if a key ever leaks the window of misuse stays small.
A connection made right now closes over TLS 1.3. The version number is something almost no visitor ever sees, and it only starts to matter when a very old device cannot open the page at all.
And the boundary of this protection: HTTPS secures the road only. The moment the data reaches the server it has left the protection of this layer. A perfectly encrypted form can store your password in a text file on a server nobody is watching. The padlock says nothing about that, and does not claim to.
What does the padlock not promise?
That the site is honest. The padlock only says the road is encrypted and that the server answering holds a certificate for this domain. About who sits behind that domain, whether the shop is real, and where the money you send ends up, it makes no claim at all.
This is not our opinion. One of the largest free certificate authorities in the world, explaining its own policy, wrote that a domain validation certificate only asserts that a public key belongs to a domain and "says nothing else about a site content or who runs it", and added that such certificates carry no information about a website reputation, real world identity or safety. In other words the issuer itself states plainly that the padlock is not a seal of approval for content.
The practical consequence is bitter and simple: a fake site can also obtain a valid certificate in minutes and show the padlock. So if your test for trusting a payment page is the presence of a padlock, you have picked exactly the test an attacker can satisfy most easily.
What you should really look at is the domain name, letter by letter: in an address, the part that matters is the one immediately before the first slash. Anything at all can be placed before it. Our position: do not look at the padlock, look at the domain, and if the link arrived by text message or through a messenger, do not click it at all and type the address yourself.
One exception, for completeness: the absence of a padlock is still a real warning. A page that shows a login or payment form without HTTPS in this day is untrustworthy with no further discussion. The padlock is a necessary condition and not a sufficient one.
What the padlock says, and what stays under the water
The road is encrypted and the certificate belongs to this domain
That is all. It is the only thing the padlock claims.
-
Who sits behind this domain
A fake site can also obtain a valid certificate in minutes.
-
Whether the content of the page is true
The issuing authority does not read the content and does not claim to have read it.
-
Where the money you send ends up
An encrypted payment page can still be somebody else payment page.
-
How the data is kept once it arrives
The protection of this layer ends at the exact moment the data reaches the server.
This drawing says nothing about the absence of a padlock. No padlock on a login or payment form is still a serious warning.
How do you move a site onto HTTPS properly?
Getting the certificate is the easiest part and the host usually does it for you. What breaks the job is the three that follow.
First, every HTTP request must go to the secure version of the same address with a 301, not to the home page. Sending everything to the home page is the simplest route and the worst one, because it kills every old link. Second, mixed content: if the page is secure but calls an image or a script from an insecure address, the browser either blocks it or warns about it. Third, the HSTS header, which tells the browser never to try HTTP again for this domain; on this site its value is one year.
One cost nobody talks about: every extra hop is a round trip. On this site, someone who types the old address rgb.ir/seo/ without https takes two hops, first from HTTP to HTTPS and then from the old address to the new one, and only after that does the first byte of the page arrive. For one visitor it does not matter; for a link repeated in ads, menus and email signatures it does. The rule is simple: wherever you have control, link the final address rather than the old one.
And its boundary: HSTS is a commitment, not a reversible setting. A browser that has seen the header will refuse to connect to your domain over HTTP until the period runs out, even if your certificate has expired. If you are not certain HTTPS is permanent, start that header with a short period.
The certificate state and expiry date of any domain can be seen in seconds with nothing installed: our free SSL check tool does exactly that. For the concept of a certificate and its types there is already the article on what SSL is, and this lesson deliberately does not repeat it.
The fast path, with AI
The ordinary way to check whether an address is healthy is to open it and look. The fast way is to take the raw header output once and force the language model to judge from that alone. The difference is that your eye sees only the final page, while that output shows every intermediate hop, every status code and every layer that touched the response on the way.
- Take the output yourself rather than asking the model for it. One line is enough: curl -sSIL http://example.com/path/. Start with http and not https, otherwise you never see the first hop, which is the important one.
- Before pasting, delete two headers: Set-Cookie and Authorization. Those are live credentials and they look harmless inside a command output.
- Hand over the recipe below together with the raw output and ask it to answer from that alone. A fast, cheap model is enough here; this is reading rather than judgement, and the current pick in each class is kept up to date in our AI reference.
- Check the answer against the output. Any header the model names that is not in your text is an invention and gets dropped on the spot.
Copy-ready recipe
You are an HTTP specialist. Judge only from the output below and add nothing to it.
Raw output (curl -sSIL, with Set-Cookie and Authorization removed):
{paste here}
What I want to know: {for example, why my old link is slow}
Write five things:
1. How many hops to the final response, and for each hop the code and the address it went to.
2. Whether a hop was spent only on going from HTTP to HTTPS. If so, say how many extra round trips that added.
3. Whether a Strict-Transport-Security header is present, and its duration.
4. From the headers, which layers touched the response: web server, page cache, content delivery network. For each one, quote the header that shows it.
5. One change I can make myself to reduce the number of hops.
Rules: a 1xx response such as 103 is not a hop and does not count. Never write a header that is not in the text above. If the data is not enough for one of the points, write "not in this output" and do not guess.Before you trust the output: Two things you have to confirm yourself. First, every header the model names must appear verbatim in your output; that is the only check that catches invention, and it takes ten seconds. Second, if the answer suggests removing a hop, make sure that old address is not linked anywhere before you touch it: deleting a redirect turns every old link into a 404, and that is hard to undo.
AI in this kind of work
On this topic a language model is very good at one job and very bad at another. Good at reading: hand it a raw header dump or a redirect chain and in seconds it explains what each line says, something that used to take weeks to learn. Bad at judging: it cannot tell you whether a site is trustworthy, because it sees exactly the two signals the attacker built.
Tools that actually help
- Claude It is built for reading the raw output of commands, and this lesson is its main use: paste the headers and ask what each one does. Iran is not on Anthropic list of supported countries, so there is no official route to sign up or pay.
- Gemini It works well for translating HTTP jargon into Persian and explaining the concepts with examples. Google own page says the Gemini app is available in more than 230 countries and territories, and Iran is not on that list.
Where it backfires
The main risk here is not what the model does not know, it is what it says with complete confidence. It takes two specific shapes. First, ask a model "is this site safe?" and it will reason that since there is a padlock and the domain looks plausible it is probably safe. The attacker supplied both of those signals, and the certificate authority itself states plainly that a certificate carries no information about a site reputation or real world identity. Detecting fraud is not a language model job, and any answer it gives is a guess in a confident tone. Second, the model invents a header name or the meaning of a status code; Anthropic itself calls this confident invention hallucination in its documentation and writes about reducing it, which means the vendor treats it as a real weakness. The remedy for both is the same: the model is allowed to explain only what you put in front of it.
Sources: Let's Encrypt: the CA role in fighting phishing and malware Anthropic: reduce hallucinations Anthropic: supported countries Google: where Gemini Apps are available
Where this advice stops
This lesson is about the protocol, not about buying and installing a certificate. Choosing a certificate type, having it issued and renewing it is a different job, covered by the article on what SSL is and the SSL certificate page, and deliberately not repeated here. Two more boundaries, stated plainly: every number here was measured from our own server in Europe and says nothing about the path an Iranian visitor travels, because this server cannot see it. And although our edge announces readiness for HTTP/3, we did not measure a full connection over it, so this lesson makes no claim about its speed.
From our own work
Four things measured on this very site on 7 September 2026, all four repeatable. First, anyone who types the old address rgb.ir/seo/ without https takes two 301 hops, the first from HTTP to HTTPS on the same path and the second to the new address, and the first byte of the page arrives only after both. Second, the certificate of this site is issued by Google Trust Services, is valid for rgb.ir and any of its subdomains, and lives for ninety days. Third, the connection closes over TLS 1.3, the page answers over HTTP/2, and the HSTS header carries a one year value. Fourth, the not found page of this site is a complete page whose HTML is more than a hundred kilobytes, which is why the text says a status code and the look of a page are independent things. The raw form of all four measurements is recorded in this session report.
Real follow-up questions
Does HTTPS push a site higher in Google?
The right form of the question is this: today HTTPS is not an advantage, its absence is a disadvantage. Every serious site is on it, so it is not what puts you ahead of anyone; but the browser announces its absence to the user next to the address, and that alone affects trust and how many people leave. If a site is still on HTTP, the reason to move is the browser, not the ranking.
What is the difference between a 301 and a 302?
A 301 says the move is permanent and a 302 says it is temporary. In practice the difference is that with a 301 a search engine replaces the old address with the new one, and with a 302 it keeps the old one because it assumes you will come back one day. Simple rule: if you are not coming back, use a 301.
I have a certificate but the browser says the connection is not fully secure. Why?
In most cases it is mixed content: the page opened over HTTPS but calls an image or a script from an HTTP address. The next two causes are also common: the certificate was issued for a different domain, for example for the version without www while the visitor arrived with www; or it has expired. All three can be told apart in seconds with the SSL check tool.