HTTPS (SSL) support - Githubissues

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

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).
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.
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.

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

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

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

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.

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.

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

Create a Dockerfile: Create a new Dockerfile in your project directory:
```
cd ~/weserv-docker
nano Dockerfile
```

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

Create a docker-compose.yml file:
```
nano docker-compose.yml
```

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

Navigate to Your Project Directory:
```
cd ~/weserv-docker
```
Build the Docker Image:
```
docker-compose build
```
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.

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=<?php echo rand(1, 10000); ?> 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. :-)

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.

weserv / images

HTTPS (SSL) support #424