Browser Mirror

A browser mirror page is a webpage that's been designed to show visitors what information is being sent by their browser*. In other words, it's like the webpage equivalent of looking into a mirror: it's reflecting your own information back to you.

This page is a bit more verbose than usual, as part of the reason I've set this up is to educate visitors about what's going on behind the scenes. While this can seem scary or overwhelming, all of the information described here is sent along with every request made by your browser. Most of it is intended to help the server* understand how to send the answer back to you -- sort of like how you might include a self-addressed stamped envelope in a business letter.

The Basics

Your IP Address
Your IP address is 3.230.119.106 . This is the "phone number" for your computer. When the server* is ready to send its reply, it will "call" your computer using this number. Here's a fun fact: if you have a web server running on your computer, entering your IP address into your browser*'s address field should let you view that server's website. In fact, if you have multiple computers and one of them has a server on it, then entering that computer's IP address in the address field of a browser* on one of your other computers should also work the same way.
Your Port Number
Your browser* is using port* 58370 to contact this server*. A simple way to understand this number would be to use a metaphor: if the IP address was your street address, then the port number is your appartment number. In other words, while the IP address tells the server* which computer to send the reply to, this tells it which "mailbox" to use. If the response was sent to the wrong port*, your computer would just ignore it.
Request Method
This page was requested using GET . There are several ways for the browser* to request information. These include GET, POST, HEAD, and PUT. GET is typically used when you click a link or enter a URL into your browser* manually, while POST is usually reserved for form submissions. The main difference you'll see is that your browser* might bring up a warning if you refresh a page that was requested using POST.

Requested URL
Unsurprisingly, this is the URL of the page you're currently viewing. Without sending this bit of information, you'd never see anything online. This field is currently /browser_mirror.html .
Query String
URLs can be full of information and weird punctuation, but they are really rather easy to understand. URLs typically contain a protocall, domain, path, and filename. They can also include a query string, which is separated from the rest of the URL by a question mark. Normally, this page doesn't use this feature, but adding a query string won't hurt it.

Techincal Stuff

Referer
The referer, as you might guess, is the URL of the page you just came from. In other words, it's the page that had the link that brought you here. Some browsers* can let you change this value to whatever you want, or even leave it blank. Such a trick can help cover your tracks online. Currently, this field was blank, so I can't tell how you got here. .
Useragent
The browser*'s user agent is a string of techincal gobbldygook that tells the server* about your browser* and its capabilities. In particular, it can be used to identify what browser* you're using, thus allowing the server* to customize its response just for you. Some browsers* let you set this yourself, so it's about as trustworthy as an online dating profile.

Your user agent is:

Additional Information

Since a browser* has no way to know what information might be useful to a server*, they usually just vomit data in the server*'s general direction and hope for the best. The information summarized above is the standard stuff that servers* work with. Beyond this point, nothing is predictable, and usually isn't recorded in a site's server logs.

Connection Information
Usually "keep-alive", this tells the server* if the browser* wants to stay in touch or not. Think of it like making a phone call and requesting to be placed on hold rather than get a call back later. Currently your browser* is saying Keep-Alive .
Cache Handling
To make things easier, the browser* keeps a copy of whatever information it recieves until it considers it "expired". This way, it doesn't waste bandwidth getting a fresh copy every time.

Your browser* didn't give my server* this information.
Accepted data types
Sometimes the browser* tries to explain what sort of information it can understand. This would be like telling someone what languages you speak. Most of the internet speaks "text/html", so that's probably going to be in this mess somewhere.

Currently your browser* is saying it accepts text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 .
Accepted languages
Similar to the previous entry, this is the browser*'s attempt to explain to the server* what languages it can use. However, this time it's talking about what languages the user (ie, YOU) can understand. This page is written using "en-US", which means "American English".

Currently your browser* is saying it accepts en-US,en;q=0.5 .
Accepted encodings
There are different ways to store data. Raw data often takes up a lot of space, and that can be a problem when sending information back to the browser*. For those of you who have had to deal with phone plans that limit the amount of data you can transfer, that's exactly what I'm talking about here. Servers* can get around these limits by using various types of compression, usually gzip and deflate. But not all programs know how to use compressed information, so some browsers* advertise what encodings they can use.

Currently your browser* is saying it accepts br,gzip .
Time of the Request
Simply put, this is when the request was made. According to your browser*, this page was requested at 7:00 on Monday, September 21st, 2020 UTC
...and more!
Everything shown so far is what I know my pages can see. It's entirely possible for there to be more information passed along with each request, but as a general rule, you need to know where to look in order to tell your webpages how to respond to information they are given. If I don't know where to look, I can't make my pages search for it.

Also, it's possible to use client-side scripts to probe your browser* for additional information. I decided not to bother, as this page is about what your browser* is telling my server*, not what I can find by getting out the latex gloves and giving your browser* a colonoscopy.