IDE, ok; prod, ok; Vagrant… come in; Vagrant
Tiny post here. I had yet again convinced myself that my dev environment was somehow deficient.
After some thought, I decided my dev environment is, more accurately, my IDE and debugger. My Vagrant VM is akin to staging, and deficient. I keep posting that I ought to give it a proper IP address and not merely port forward. Perhaps this is common knowledge. The more I write it the more ingrained it becomes.
It needs to become second nature. Replicating production in a VM with port forwarding instead of a dedicated IP is not accurate. My recent endeavours in TLS termination hinted that port forwarding can work as (I) intended. The whole process of TLS termination is to ensure that forwarding works. Spinning up a Vagrant and ad-hoc mapping some ports to it is another kettle of fish.
I recently went through all my permalinks and removed trailing slashes and trailing slashes followed by hashes. They wouldn't work, for whatever reason. FastAPI has some kind of redirection (I commonly see 307 in the logs) that means the forwarded port gets discarded. I don't know the details, but everytime I am surprised by it.
If my Vagrant is listening to port 443, from port 5432 on the host, then browsing to https://127.0.0.1:5432/ci-cd/quick-and-cheap-azure-vms/#resource-groups will drop the port in the redirection process. Rarely, my dev server might be up, and using port 80 so this could go unnoticed. The same applies to trailing slashes.
I'm pretty sure I wasted a whole day because of port forwarding when I investigated failures recognising URLs that ended with trailing slashes, as I moved this site to FastAPI. Indirection is a notorious problem in software engineering.
I'm trying to make a case for switching from port mapping to a dedicated IP. I am a little invested in the former solution but am beginning to see it doesn't scale so well.
When I have the slightest suspicion that browsing through my locally virtualised environment is not going to plan, I must disregard what the browser says and instead execute the equivalent curl from within the VM. It's only within the VM that ports 443 and 80 are as they would be expected in every public server on the net.
4 curl flags you need to know
This means knowing a thing or two about
-kwill accept self signed (or any) certificate.
-Lwill follow links. This is the default behaviour of the browser.
-Igets the headers. Sometimes they contain locations of interest. Ultimately, this seems to be met by a 405 response, "Method Not Allowed". That's because instead of a GET, the method is HEAD.
-iwill get around a 405 from
-I, but will contain a lot of body. Pipe it to
Checking the full responses will be horrible. A test based browser might be slightly easier. I recommend Lynx but haven't used it in so long that I would rather prove just the concept I need to, with curl, and move on.
Peace of mind is a bargain, at just an hour on a public cloud VM. If it works before staging with TLS forwarding, ie, in my IDE, it'll be fine in production. I don't need to change TLS forwarding and this behaviour is, by now, expected. I don't need it, but Traefik looks so interesting...