apt update failing with connection failed

Today, attempting apt update was failing:

Hit:1 http://deb.debian.org/debian bullseye InRelease
Err:2 http://security.debian.org/debian-security bullseye-security InRelease
  Connection failed [IP: 151.101.166.132 80]
Err:3 http://deb.debian.org/debian bullseye-updates InRelease
  Connection failed [IP: 151.101.166.132 80]
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: Failed to fetch http://deb.debian.org/debian/dists/bullseye-updates/InRelease  Connection failed [IP: 151.101.166.132 80]
W: Failed to fetch http://security.debian.org/debian-security/dists/bullseye-security/InRelease  Connection failed [IP: 151.101.166.132 80]
W: Some index files failed to download. They have been ignored, or old ones used instead.

I was able to access the resources in my browser, which was redirected to https.

So I updated /etc/apt/sources.list, changing http to https throughout and then apt update completed without errors.

Hit:1 https://deb.debian.org/debian bullseye InRelease
Get:2 https://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:3 https://security.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Get:4 https://security.debian.org/debian-security bullseye-security/main Sources [192 kB]
Get:5 https://security.debian.org/debian-security bullseye-security/main amd64 Packages [236 kB]
Get:6 https://security.debian.org/debian-security bullseye-security/main Translation-en [154 kB]
Fetched 675 kB in 5s (138 kB/s)                            
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
68 packages can be upgraded. Run 'apt list --upgradable' to see them.

The original sources had been working for well over a year. It seems http is no longer supported.

@ig3/couchapp is deprecated

 @ig3/couchdb is deprecated.

It works with CouchDB 3.x but vhost and rewrite rules are deprecated and planned to be removed from CouchDB 4. Without them, couchapps will not work.

The primary feature of a couchapp is that it is served from a CouchDB server. No other server is required.

The concept of a CouchApp arose with CouchDB. But, as the CouchDB docs indicate, CouchApps are deprecated:

Note: Previously, the functionality provided by CouchDB’s design documents, in combination with document attachments, was referred to as “CouchApps.” The general principle was that entire web applications could be hosted in CouchDB, without need for an additional application server.

Use of CouchDB as a combined standalone database and application server is no longer recommended. There are significant limitations to a pure CouchDB web server application stack, including but not limited to: fully-fledged fine-grained security, robust templating and scaffolding, complete developer tooling, and most importantly, a thriving ecosystem of developers, modules and frameworks to choose from.

The developers of CouchDB believe that web developers should pick “the right tool for the right job”. Use CouchDB as your database layer, in conjunction with any number of other server-side web application frameworks, such as the entire Node.JS ecosystem, Python’s Django and Flask, PHP’s Drupal, Java’s Apache Struts, and more.

Several tools have been written to automate building and deploying CouchApps. The earliest I know about were developed by Chris Anderson. Some history is available in the post: What is Couchapp?.

I had been using a node based implementation of the couchapp tool but when I set up a new CouchApp early 2022 I found it no longer worked. I forked it and released @ig3/couchapp but learned that CouchDB had deprecated the features that make CouchApps possible.

So I rebuilt my CouchApp / couchapp based apps using a combination of nginx and CouchDB.

It isn't hard.

Everything comes from nginx:

 * static content is served by nginx directly

 * CouchDB access is proxied by nginx

 * Rewrite rules are written in nginx

 A very simple app might be configured in nginx as:

server {
  server_name mycoucnapp.example.com;
  listen 443 ssl http2;

  client_max_body_size 8M;

  location / {
    root /usr/local/data/mycouchapp/attachments;
    try_files $uri /index.html;
  }

  location /couchdb {
    proxy_pass http://localhost:5984/;
  }
  location /couchdb/ {
    proxy_pass http://localhost:5984/;
  }
}

Note the trailing slashes on the URLs to proxy_pass. They are 
significant. Without them, the entire request path is passed to CouchDB.
With them, the / replaces the location (/couchdb or /couchdb/).