this post was submitted on 29 May 2024
106 points (96.5% liked)

Programming

16343 readers
204 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] v9CYKjLeia10dZpz88iU 13 points 1 month ago* (last edited 1 month ago) (2 children)

I disagree.

You shouldn't serve anything over http. (The article argues that there's risk of leaking user data) Whatever you're using for a webserver should always catch it. A 301/308 redirect is also cached by browsers, so if the mistake is made again, the browser will correct it itself.

If you make it fail, you're just going to result in user confusion. Did they visit the right website? Is their internet down? etc.

[–] [email protected] 47 points 1 month ago* (last edited 1 month ago) (1 children)

This article isn't about browsers or websites, and even acknowledges in the opening that it makes sense as a usability tradeoff in that context.

[–] v9CYKjLeia10dZpz88iU 15 points 1 month ago (1 children)

I clearly didn't read it. It makes sense, if users aren't visiting the API then it really doesn't matter that it's not redirected on insecure connections.

[–] [email protected] 10 points 1 month ago* (last edited 1 month ago)

I clearly didn’t read it.

I love the honesty. It's really refreshing to see someone take accountability instead of becoming defensive.

[–] Mikina 4 points 1 month ago* (last edited 1 month ago)

I'd like to mention one exception, because it took me ages to properly debug.

If your endpoint is serving mirrors for APT, don't redirect to HTTPS.

APT packages are signed and validated, so there is no need to use TLS. Lot of docker images (such as Kali) do not have root certificates by default, so they can't use the TLS, because cert validation fails. You also can't install the certificates, because they install through APT. If your local mirror redirects to https by default, it will break it for people who choose the mirror, which IIRC happens automatically based on what's closest to you. I think this issue is still there for Czech Kali package mirror, and it took me so long to figure out (because it's also not an issue for most of the users, since they have different mirrors), so I like mentioning this when talking http/s. It's an edge case, but one that I find interresting - mostly because it would never occur to me that this can be an issue, when setting up a mirror.

But that was more than a year ago, it may be better now.