Resizing photos in PHP with correct orientation/rotation and retaining EXIF data

▼ When I got my first iPhone back in 2008, I hacked together a quick script that let me post photos from my iPhone to my website. However, iPhone photos are now 3 MB or larger, which is a bit much. So in practice I would edit the photos on my computer before posting them. But that gets old, so time for some automation.

The first photo I uploaded directly from my iPhone 3G, showing part of the script

Actually resizing images is easy enough in PHP using the imagecopyresampled() function. However, using the provided example script the result was that a photo that I took with my iPhone showed up rotated.

The reason for that is that phone cameras store the camera's rotation in the EXIF data, and the PHP image manipulation functions strip away the EXIF data. One way to solve this is to read the EXIF data using exif_read_data() and then rotate the image accordingly using the imagerotate() function as explained here. However, that still leaves an image with no EXIF data.

A better way to do that is by copying all the EXIF data from the original image to the resized image. This requires a bit of work, but there is a good example transferIptcExif2File() function in the user contributed notes for the PHP iptcembed() function.

Searching for this using Google didn't give me any results, so hopefully the above will be helpful to others running into the same problem. And as you can see, it works:

Permalink - posted 2021-11-28

The HTTPS and HTTP conundrum

▼ The past few days I have added HTTPS support to bgpexpert.com and iljitsch.com. About ten years ago, I experimented a bit with SSL/TLS (HTTPS) support in Apache, and that was rather difficult.

But no more. Thanks to the efforts of Let's Encrypt and the ACME protocol as implemented in certbot, adding HTTPS support to your websites is now almost ridiculously easy: just install certbot, run it with --apache and a list of your domains... and that's it! (Remember those certs expire in 90 days, so set up automatic renewal.) I was initially worried about the number of subdomains I use, but 30 of them is not a problem.

However, there are complications, which all go back to the rather bad decision to use HTTPS rather than HTTP in URLs and use a separate port number for HTTPS. This means that you can't just negotiate the best security supported by both sides. Instead, HTTP is never encrypted, and HTTPS is always encrypted.

So that means if you just enable HTTPS and do nothing else, all the visitors to your website will still use HTTP. I'm actually fine with that, as I feel that providing the option to encrypt an HTTP session is sufficient. In my opinion, for the sites I'm running, being able to access them over HTTP should HTTPS not work is a pro, not a con. Should you wish to go further, the recommended approach is to have your web server redirect requests from HTTP to HTTPS.

What I'm doing here on iljitsch.com is just enable HTTPS and see what happens. I'm especially interested in seeing if/when/how Google will discover the new HTTPS capability. Once you're on on iljitsch.com using HTTPS, I want to keep you there, so I've changed all the links to use protocol-relative URLs. As I'm using subdomains for some stuff, I do need to specify www.iljitsch.com, but I do that by using //www.iljitsch.com/ rather than http://www.iljitsch.com/ or https://www.iljitsch.com/, so if you're on HTTP, the links will be HTTP links, but if you're on HTTPS, the links will be HTTPS links.

On bgpexpert.com, on the other hand, I want Google to find the HTTPS version of the site as soon as possible, so I've changed some of the scripts to redirect from HTTP to HTTPS, along with using relative or protocol-relative URLs everywhere. However, in the future I may remove these redirects and use other mechanisms to make Google prefer the HTTPS version rather than the HTTP version of the site. Not entirely sure yet what's the best way to do that.

One benefit of using HTTPS is that links to my images on other sites, including RSS readers, now work. So let me take advantage of that.

Permalink - posted 2021-11-22

Test post preparing for HTTPS

▼ For some time now there's been a push to move the entire web from HTTP (no encryption) to HTTPS (with encryption).

I never felt it was necessary to encrypt static content. But the time has come to cave to peer pressure, and enjoy a few benefits such as the ability to post images to web forums.

However, I still feel very strongly about everything remaining accessible over HTTP. If you go HTTPS-only, you are now relying on a certificate authority (as well as your own ability to keep certificates up to date!), and you're cutting off some older systems and losing some performance. Also, having to change everything wholesale will be somewhat of a nightmare.

The trouble is: how do use HTTP images and links on an HTTP page and HTTPS images and links on the HTTPS version of the same page? With dynamically generated pages that's not too difficult: just let the script insert HTTP or HTTPS as required. Or, even easier: use relative links, that don't include the domain name.

Unfortunately, I have my content spread around a number of subdomains, and most of it is in static pages.

Turns out that you don't have to choose between:

http://www.iljitsch.com/2021/11-20-test-post.html (absolute URL)

and

/2021/11-20-test-post.html (relative URL)

but you can also use:

//www.iljitsch.com/2021/11-20-test-post.html

That's a protocol-relative URL. So you do specify the domain name, but not HTTP or HTTPS (or any other protocol). So if you use such a URL as a link on an HTTP page, the link will use HTTP. If you use it on an HTTPS page, the link will use HTTPS. So that's perfect for links within the site and images on static pages that may be served over either HTTP or HTTPS.

Paul Irish has a blog post that initially explained that it's a good idea to use protocol-relative URLs, but the current wisdom (added to that post) is they are better avoided, as there may be some cross site scripting possibilities. But as I don't use any cross site scripting on iljitsch.com that's not an issue here.

So I still need to go over the entire website to make sure protocol-relative URLs are used where I can't use regular relative URLs.

Apart from that, the main complication is my RSS feeds. Unless I'm misremembering, I started using absolute paths for my images because otherwise the images wouldn't show up properly on RSS aggregators. So I probably need to rewrite relative and protocol-relative URLs in my RSS feed script.

This is a test post to see how relative and protocol-relative images and links are handled in RSS. So don't be alarmed if links or images in this post don't work if you're viewing this post through an RSS aggregator.

Let me plug Esperanto and do the opposite for nuclear energy with this relative image (link):

Then again, fossil fuels aren't ideal either, using a protocol-relative image URL (link):

More later.

Permalink - posted 2021-11-20

Dutch cabinet says BGP in good hands at IETF in response to Facebook incident

▼ Laurens Dassen, a new member of the Dutch parliament after the March elections, representing the pan-European party Volt, put several questions about the October 4th Facebook outage to the Dutch cabinet (administration). Yesterday, minister Blok of the ministry of Economic Affairs and Climate answered those. The fourth question was about BGP, among other things.

The Facebook outage was caused by installing a BGP configuration with an error in it. Which underlines what I've been saying for a long time: when all the important parts of your network are redundant and you're using BGP to reroute automatically when failures happen, the remaining outages are your fault. So quite a heavy responsibility. Redundancy wasn't an issue with this incident: Facebook has datacenters all over the world. But if you use automated tools to push out a broken configuration to all of them at once, then it's game over. Remote access also didn't work anymore, and I gather that even access to the buildings didn't work anymore. Probably not exactly what Zuckerberg had in mind with move fast and break things.

See the Dutch version of this post or use Google Translate to read the relevant question and the answer.

The main points: BGP worked correctly and BGP is being developed by the IETF, which is an appropriate forum for that work.

They probably don't realize that BGP has been essentially the same for 27 years: in 1994 BGP version 4 was defined and that's the version we still use today, with relatively minor additions.

Further reading and listening:

• Presentation NL-ix BGP security update
• Geoff Huston's Survey on Securing Inter-Domain Routing part one en part two (beginner-onvriendelijk) en "epic diatribe" in podcast-vorm over dit onderwerp, ook in twee delen: part 1 and part 2

Permalink - posted 2021-11-11 - 🇳🇱 Nederlandse versie

Review: Peak Design Anchor Links to quick-release your camera strap

▼ I've had a few Nikon cameras, and those always come with a perfectly usable strap. The only issue is that putting the strap on a camera and getting the length just right is a rather involved process.

And sometimes I need a strap, but in other situations, it gets in the way. So I asked about straps that are easy to attach and detach in a forum, and one of the suggestions was for a Peak Design strap.

Peak Design as an entire system, with different kinds of straps that all use the same quick release mechanism. Their straps seem pretty good but a bit more than what I need for my non-pro cameras and matching lenses.

So I decided to get the Peak Design Anchor Links. (About $20/€20.)

This is a small set that contains:

1. Four anchors
2. Two anchor links
3. Two rings

If you're into watching Youtube photography channels, you've probably seen the little black discs with a red edge that hang off of the sides of a camera before. The anchors click into the anchor links, which are of course attached to the ends of a strap.

A Nikon strap with anchor links on the ends and the anchors in the middle:

The anchors are quite small, here compared to some coins: 20 South African rand cents, 1 US dollar cent, 1 euro cent and 10 Canadian dollar cents:

The anchor's cord loops attach quite nicely to a Panasonic DMC-TZ70 compact camera:

However, the cord won't go through the holes on most Nikon cameras. I used the included rings with this Z fc:

On the Nikon F65 on the left there are no issues attaching the anchors, and on the D7100 on the right I used the triangles that the Nikon strap normally loops through. Not very elegant, though:

Verdict:

Attaching to many Nikon cameras is not ideal, but being able to take off the camera strap in seconds is really great.

The system is rated for 90 kg. When you start to see the yellow core of the anchor cords, you know it's time to replace the anchors. The anchors definitely won't come out of the links by themselves: you have to push the anchor down and slide it up until it comes out of the anchor link. So this seems like a very secure system.

The anchors are plastic so they won't scratch your camera, but I believe the anchor links are aluminum, so you'll probably want to take off the strap when putting away the camera.

I like the fact that you get four anchors, so you can outfit two cameras with anchors. Also, the anchors themselves are pretty easy to attach/detach, so you can use them with even more cameras without much trouble.

The only thing that could make this better would be "slim anchors" option with thinner cords for lighter cameras.

Highly recommended.

Permalink - posted 2021-10-16