HTTPS (SSL) support

[degarb]

I managed to install weserv on my windows 11 laptop, after I realized there is internal ip forwarding within the laptop (dos command) to the wsl listening port, which is different than the machin port.

I still cant use my laptops weserv since my website is https and modern browsers do not display http: images in Https: pages.

My hosting company now offers subdomains with dynanmic dns updating urls and offers ssl certificate, authority bundle, and private key.

I can't find documentation for easily pasting these somewhere to get weserv to use https.

My paid chatpt offered me 10 pages on instructions without any satifying explanation. So, I am sure it will not work, per 24 years of experience following complex linux instructions. Anything over 4 paragraphs, never works, due to localizations, caveats, typos, assumptions by the instructor, etc. The ai wants reverse proxies and other voodoo wizzard commands, I don't feel comfortable.

I compained that the instructions were too complex and involved seemingly silly reverse proxied, and it gave me the following less convoluted instructions. I am not sure I trust the instructions to work or not mess up my working weserv: Ai ,"I understand the frustration with the complexity of setting up SSL with additional tools like Nginx. However, Nginx is commonly used because it efficiently handles SSL termination and reverse proxying. If you prefer not to use Nginx and are looking for a simpler solution, you might need to configure the weserv service itself to use SSL, if it supports such configuration directly.

Here's a simpler approach without introducing Nginx, assuming weserv can be configured to handle SSL directly.

Step-by-Step Guide to Using SSL Directly with weserv in Docker

1. Prepare Your SSL Certificate:
   Ensure you have the SSL certificate (thunder.clevelandohioxxx.com.crt), private key (thunder.clevelandxxx.key), and the intermediate certificate (if applicable, intermediate.crt).

2. Modify Dockerfile for weserv (if needed):
   You might need to modify the Dockerfile for the weserv image to include SSL support if it's not already present. However, this might require some custom configuration depending on the base image used by weserv.

3. Docker Compose Configuration:
   If weserv itself can handle SSL, you'll configure it directly within your docker-compose.yml file. Here's a hypothetical example (note that this assumes weserv's Docker image or underlying service supports SSL configuration directly):

version: '3'
services:
  weserv:
    image: weserv/images:latest
    ports:
      - "80:80"
      - "443:443"
    environment:
      - SSL_CERT_PATH=/etc/ssl/certs/thunder.clevelandXXX.com.crt
      - SSL_KEY_PATH=/etc/ssl/private/thunder.clevelandxxx.com.key
      - SSL_INTERMEDIATE_PATH=/etc/ssl/certs/intermediate.crt  # If applicable
    volumes:
      - ./ssl/certs:/etc/ssl/certs
      - ./ssl/private:/etc/ssl/private

Explanation:

• SSL_CERT_PATH, SSL_KEY_PATH, SSL_INTERMEDIATE_PATH: Environment variables (hypothetical) for SSL paths.
• volumes: Mount local SSL certificate and key files into the Docker container.

4. Directory Structure and SSL Files:
   Ensure your directory structure looks like this:

~/weserv-docker/
|-- docker-compose.yml
|-- ssl/
    |-- certs/
        |-- thunder.clevelandohioxxx.com.crt
        |-- intermediate.crt  # If applicable
    |-- private/
        |-- thunder.clevelandxxx.com.key

5. Start Docker Container:
   Navigate to your project directory and start the container:

cd ~/weserv-docker
docker-compose up -d

6. Verify Configuration:
   Open your browser and navigate to https://thunder.clevelandxxx.com.

Important Notes:

• This approach assumes the weserv Docker image or the underlying service supports direct SSL configuration. If not, you may need to delve into modifying the Docker image or using a different service that does support SSL natively.
• If weserv doesn’t support SSL configuration directly, using a reverse proxy like Nginx (as initially described) is a standard approach to handle SSL termination.

If you find that weserv does not support SSL configuration directly and you must use a reverse proxy, please let me know, and I can assist in simplifying the process or explore alternative solutions.

my site is a weather site and I xxx over part of the name. I realize it now looks like a xxx site that I am squeezing the images to the lowest resolution possible, lol. No, I use weserv and my site to get 200 megs of weather products down to 1 meg, so I don't blow out my phone data by just reloading my weather 4 or 5 times a day on iffy weather days.

[andrieslouw]

Thanks for the feedback, we use the source code with https (on wsrv.nl) and indeed use nginx as a reverse proxy to do so (also for http). This is actually quite fast, and there is nothing wrong with using nginx in this way, as you can also benefit from the proxy_cache in this way.

I fully agree with you that we should share how we do this ourselves, as https is quite standard and mandatory these days. And we already maintain this code for the public service.

Lets keep this issue open, and we will look at sharing the nginx-config we use, and give some guidance on how to use it in docker, to make it easier for others.

[degarb]

weserv.nl rocks! Thanks for it. I use it everyday for my personal use over cell when my server gets the android browser id. If I figure out how to use the https, I will have a fall back. I will want to eventually learn how to back up the entire docker image so I can fully sleep at night.

Do these instructions look right? I would probably clone my working docker image, before I risk screwing it up. So, I added the first step for a hypothetical clone. Obviously I would need to unload that process and start the clone to test.
It's looks like a lot of work, and would rather get verification before ai pushes me down some 7 hour rabbit hole of trouble shooting.

Hypothetical ai weserv ssl instructions:

Yes, you can clone your Docker image to create a new instance that you can work on without affecting the known working image. This is done by tagging the existing image with a new name and then operating on the clone. Here’s how you can do it:

Step-by-Step Guide to Cloning a Docker Image

Step 1: List Your Docker Images

First, list all your Docker images to find the one you want to clone:

docker images

You will see an output like this:

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
weserv/images       latest              d1e1c3d3a1b1        2 days ago          800MB

Assuming weserv/images:latest is your working image.

Step 2: Tag the Existing Image with a New Name

Tag the existing image with a new name to create a clone:

docker tag weserv/images:latest weserv/images:clone

Step 3: Verify the New Image

List your Docker images again to verify the new image:

docker images

You should see an output including your cloned image:

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
weserv/images       latest              d1e1c3d3a1b1        2 days ago          800MB
weserv/images       clone               d1e1c3d3a1b1        2 days ago          800MB

Step 4: Create a Dockerfile for SSL Support

Now you can create a Dockerfile for the clone image to add SSL support without affecting the original image. Follow the instructions provided earlier for creating the Dockerfile and Nginx configuration.

Step-by-Step Guide for Custom Dockerfile

1. Create a Dockerfile:
   Create a new Dockerfile in your project directory:

   cd ~/weserv-docker
   nano Dockerfile

2. Add the Following Content to the Dockerfile:

   # Use an official Nginx image as the base
   FROM nginx:latest
   
   # Copy Nginx configuration file
   COPY nginx/nginx.conf /etc/nginx/nginx.conf
   
   # Copy SSL certificates into the container
   COPY ssl/certs/thunder.cocomoweatherforecast.com.crt /etc/ssl/certs/
   COPY ssl/private/thunder.cocomoweatherforecast.com.key /etc/ssl/private/
   COPY ssl/certs/intermediate.crt /etc/ssl/certs/  # If applicable
   
   # Expose ports
   EXPOSE 80
   EXPOSE 443
   
   # Start Nginx
   CMD ["nginx", "-g", "daemon off;"]

Step 5: Create Docker Compose File

1. Create a docker-compose.yml file:

   nano docker-compose.yml

2. Add the Following Content:

   version: '3'
   services:
     nginx:
       build: .
       image: weserv/images:clone
       ports:
         - "80:80"
         - "443:443"
       depends_on:
         - weserv
   
     weserv:
       image: weserv/images:latest
       ports:
         - "8080:8080"

Step 6: Build and Run Docker Containers

1. Navigate to Your Project Directory:

   cd ~/weserv-docker

2. Build the Docker Image:

   docker-compose build

3. Start the Docker Containers:

   docker-compose up -d

Step 7: Verify Configuration

Open your browser and navigate to https://thunder.cocomoweatherforecast.com. You should see your weserv service running securely with SSL.

Summary

• Cloning the Image: By tagging the existing image with a new name, you create a clone that you can safely modify.
• Creating Custom Configuration: Use the Dockerfile and docker-compose.yml to configure and run the cloned image with SSL support.
• Testing: Ensure the new configuration works without affecting the original image.

This approach allows you to experiment with SSL configurations on a cloned Docker image without risking your known working setup.

[degarb]

Thanks for the feedback, we use the source code with https (on wsrv.nl) and indeed use nginx as a reverse proxy to do so (also for http). This is actually quite fast, and there is nothing wrong with using nginx in this way, as you can also benefit from the proxy_cache in this way.

I fully agree with you that we should share how we do this ourselves, as https is quite standard and mandatory these days. And we already maintain this code for the public service.

Lets keep this issue open, and we will look at sharing the nginx-config we use, and give some guidance on how to use it in docker, to make it easier for others.

Speaking of weserv.nl, I have been using for years, and cache. For weather images I don't want cache and usually don't have problems getting a new version of a weather image.

there is one weather radar image today that I can't get a new version of with weserv.nl no matter what: <img src="https://images.weserv.nl/?url=https://radar.weather.gov/ridge/standard/KCLE_0.gif&t=square&q=28&output=webp&a=top&Cache-Control=max-age=0&rand= Max age is 0, but I tried 1, etc, I manually changed the parameter to other random numbers. I am only getting weird old radars from the past on this radar image, only. On others, I get fresh weather images.

On my home weserv, the cache is working as expected and I can get a fresh radar, no problem.

As I said, this is the first in years, and its probably a hiccup above the weserv.nl and on an upstream cloudflare cache or something. I assume weserv.nl and weserv github are technically separate, so I didn't post as a weserv issue, which it is likely not. This is the first time I have seen this with weserv.nl I used imagick php to convert the image, but it is dog slow, compared with weserv. I was able to use my imagick.php to produce modest animation size reductions. It crops, rather than resizes and chokes the php server on large animations, and it has a frame jump issue, but on a 600kb version of the image I posted I was able to get the image to 266 kb, and see the direction of the storms. But it takes 25 seconds and totally choked the php server on greater than 1 meg animations, lol. Weserv.nl is nearly instananeous on all images even though we are across the Atlantic, your servers ( I assume) in the Netherlands, and I in Ohio--I mean Cocomo. :-)

[irqus]

Thanks for the feedback, we use the source code with https (on wsrv.nl) and indeed use nginx as a reverse proxy to do so (also for http). This is actually quite fast, and there is nothing wrong with using nginx in this way, as you can also benefit from the proxy_cache in this way.
I fully agree with you that we should share how we do this ourselves, as https is quite standard and mandatory these days. And we already maintain this code for the public service.
Lets keep this issue open, and we will look at sharing the nginx-config we use, and give some guidance on how to use it in docker, to make it easier for others.

Speaking of weserv.nl, I have been using for years, and cache. For weather images I don't want cache and usually don't have problems getting a new version of a weather image.

there is one weather radar image today that I can't get a new version of with weserv.nl no matter what: <img src="https://images.weserv.nl/?url=https://radar.weather.gov/ridge/standard/KCLE_0.gif&t=square&q=28&output=webp&a=top&Cache-Control=max-age=0&rand= Max age is 0, but I tried 1, etc, I manually changed the parameter to other random numbers. I am only getting weird old radars from the past on this radar image, only. On others, I get fresh weather images.

On my home weserv, the cache is working as expected and I can get a fresh radar, no problem.

As I said, this is the first in years, and its probably a hiccup above the weserv.nl and on an upstream cloudflare cache or something. I assume weserv.nl and weserv github are technically separate, so I didn't post as a weserv issue, which it is likely not. This is the first time I have seen this with weserv.nl I used imagick php to convert the image, but it is dog slow, compared with weserv. I was able to use my imagick.php to produce modest animation size reductions. It crops, rather than resizes and chokes the php server on large animations, and it has a frame jump issue, but on a 600kb version of the image I posted I was able to get the image to 266 kb, and see the direction of the storms. But it takes 25 seconds and totally choked the php server on greater than 1 meg animations, lol. Weserv.nl is nearly instananeous on all images even though we are across the Atlantic, your servers ( I assume) in the Netherlands, and I in Ohio--I mean Cocomo. :-)

we are having the same problem, we have an images server that updates each image regularly each day, in our self-hosted weserv.nl, the images got regenerated if we specify the Cache-Control=max-age=0, but not in the images.weserv.nl side.

in another project we're using Flyimg project, it uses php and imagemagick, but the response time is speedy especially for caching, also when we want to refresh the cache, we can pass a parameter rf_1 and we got what we need.

I didn't want to compare projects here, I think both are great projects and a lot of effort was put into them.

[degarb]

Before I mess with my 10 step ai instructions to install the ssl with weserv, I thought it would be easier to write a pass through php to run on the hosted https page, which would allow me to embed my home processed http images in an https page.

It doesnt work. it appears weserv is blocking the curl connections needed on the php I wrote and an opensourced annonymizing proxy.

Does anyone remember in the code where this might be blocked and how to unblock it?

[degarb]

Example:
-- https://radar.weather.gov/ridge/standard/KCLE_0.gif?random=1404121579
--pass through proxy location : https://clevelandohioweatherforecast.com/php-proxy/
--working image on the proxy: https://clevelandohioweatherforecast.com/php-proxy/index.php?q=https%3A%2F%2Fradar.weather.gov%2Fridge%2Fstandard%2FKCLE_0.gif%3Frandom%3D1404121579
--working image on home weserv : http://thunder.clevelandohioweatherforecast.com:8080/?url=https%3A%2F%2Fradar.weather.gov%2Fridge%2Fstandard%2FKCLE_0.gif&t=square&w=400&q=28&output=webp&a=top&Cache-Control=max-age=0&rand=4032
--proxy unable to connect with http://myweserv : https://clevelandohioweatherforecast.com/php-proxy/index.php?q=http%3A%2F%2Fthunder.clevelandohioweatherforecast.com%3A8080%2F%3Furl%3Dhttps%253A%252F%252Fradar.weather.gov%252Fridge%252Fstandard%252FKCLE_0.gif%26t%3Dsquare%26w%3D400%26q%3D28%26output%3Dwebp%26a%3Dtop%26Cache-Control%3Dmax-age%3D0%26rand%3D4032

[degarb]

And on the proxy I wrote: https://clevelandohioweatherforecast.com/pFad/index.php?u=http://thunder.clevelandohioweatherforecast.com:8080/?url=https%3A%2F%2Fradar.weather.gov%2Fridge%2Fstandard%2FKCLE_0.gif&t=square&w=400&q=28&output=webp&a=top&Cache-Control=max-age=0&rand=4032

or , here is a simple curl php: <?php

// Get the homeurl parameter
$homeUrl = isset($_GET['homeurl']) ? $_GET['homeurl'] : null;

if (!$homeUrl) {
header('Content-Type: text/plain');
die('URL parameter "homeurl" is required.');
}

// Decode the URL if it's encoded
$homeUrl = urldecode($homeUrl);

// Debugging: Show the URL that will be used
header('Content-Type: text/plain');
echo "Processed URL: $homeUrl\n";

// Initialize cURL session
$ch = curl_init($homeUrl);

// Set cURL options
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_MAXREDIRS, 10); // Follow up to 10 redirects
curl_setopt($ch, CURLOPT_USERAGENT, 'Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.18');
curl_setopt($ch, CURLOPT_TIMEOUT, 300); // Set to 5 minutes
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 120); // Connection timeout
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); // Disable SSL verification
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false); // Disable SSL verification
curl_setopt($ch, CURLOPT_PORT, 8080); // Specify port 8080
curl_setopt($ch, CURLOPT_VERBOSE, true); // Enable verbose output for debugging

// Execute the cURL request
$imageData = curl_exec($ch);
$httpStatus = curl_getinfo($ch, CURLINFO_HTTP_CODE);
$curlError = curl_error($ch);
$curlInfo = curl_getinfo($ch);
curl_close($ch);

if ($imageData === false || $httpStatus != 200) {
header('Content-Type: text/plain');
echo "Error fetching the image: $curlError HTTP Status: $httpStatus\n";
echo "Verbose cURL info: " . print_r($curlInfo, true);
exit;
}

// Output the fetched image data
header('Content-Type: image/' . pathinfo($homeUrl, PATHINFO_EXTENSION));
echo $imageData;

?>
Unfortunately, the seemingly simple workaround for getting my home http weserv to work wrapped in the https doesn't work.

I did add this to the php.ini :
allow_url_fopen = On
allow_url_include = On

[kleisauke]

we are having the same problem, we have an images server that updates each image regularly each day, in our self-hosted weserv.nl, the images got regenerated if we specify the Cache-Control=max-age=0, but not in the images.weserv.nl side.

For self-hosted instances using only Nginx as a caching layer, you can send the Pragma: no-cache header to bypass all intermediary caches.

images/ngx_conf/imagesweserv.conf

Line 145 in a6d7413

proxy_cache_bypass $http_pragma $http_authorization;

In most modern web browsers, this is done automatically when you perform a force reload, usually by pressing CTRL + F5.

[degarb]

I always use browsers that empty data on exit and only ever control f5. I even have duckduckgo browser that auto deletes cache every 5 minutes. I dont run any special weserv from the house. I have no problem getting a new image using my server. I have only noticed the problem on one image with weserv.nl:
https://images.weserv.nl/?url=https://radar.weather.gov/ridge/standard/KCLE_0.gif&t=square&q=28&output=webp&a=top&Cache-Control=max-age=0 I cant even cachebust with a random number parameter using php

It is logical it is going to happen on other weather images, but I haven't noticed, so far.

I have some other pressing computer priorities, and was really interested on your or your brother's comments on the ai instructions for installing the ssl on my home weserve, before I proceeded. I might get around to jumping in by the end of the month, but it is an extremely busy time of the year, and I fear what seems like an hour of instructions will turn into another focused obcession of mine that will take a day to succeed, if not a day and a half. lol.