No log or proxy pass for chunked transfer encoding

1. Caddy version (caddy version):

v2.2.1 h1:Q62GWHMtztnvyRU+KPOpw6fNfeCD3SkwH7SfT1Tgt2c=

2. How I run Caddy:

a. System environment:

FROM caddy:2.2.1-builder AS builder

RUN xcaddy build \
    --with github.com/gamalan/caddy-tlsredis


FROM caddy:2.2.1-alpine

RUN apk add --no-cache \
     ca-certificates curl \
  && rm -rf /tmp/* \
  && rm -rf /var/cache/apk/*


COPY --from=builder /usr/bin/caddy /usr/bin/caddy

I have some additional code that copies over the config file on container startup and does some checks but otherwise should have no effect on execution.

b. Command:

caddy run --watch --config "$filePrefix/build/configs/turbokivaweb/migration.caddy" --adapter caddyfile

c. Service/unit/compose file:

version: "3.4"

services:
  turbokivaweb:
    build:
      context: ..
      dockerfile: build/dockerfiles/caddy.dockerfile # See above
    ports:
      - "8088:8088"
    links:
      - php
  php:
    build:
      context: ..
      dockerfile: build/dockerfiles/php.dockerfile # php:8-fpm-alpine with some extensions installed

d. My complete Caddyfile or JSON config:

(turbokivaweb) {
	encode gzip
	handle {
		php_fastcgi php{$web_upstreamSuffix}:9000
	}
	handle_errors {
		rewrite * /static/errorPages/general.html
		templates
		file_server
	}
}
:8088 {
	import turbokivaweb
}

3. The problem I’m having:

I am trying to POST a form to a PHP script. It seems caddy never logs the request and PHP never receives the request. There are no errors on the client like connection refused or connection closed; it just hangs waiting for a response.

Here’s the distilled client: http://cybercoment.com/temp/vertxtest%20cleaned.zip

Relevant code:

Vertx vertx = Vertx.vertx();
MultiMap values = MultiMap.caseInsensitiveMultiMap();
values.add("field1", "value1");
values.add("field2", "value2");
final WebClient client = WebClient.create(vertx);
final HttpRequest<Buffer> request = client.post(8088, "localhost", "/");
System.out.println("Sending request");
final HttpResponse<Buffer> response = request
		.rxSendForm(values)
		.blockingGet();
System.out.println("Response received:");

Run with gradle run
Actual output:

cosmotic@Hank~/Desktop/vertxtest/:gradle run

> Task :run
Java 14.0.1
Sending request
<=========----> 75% EXECUTING [46s]
> :run

Expected output:

cosmotic@Hank~/Desktop/vertxtest/:gradle run

> Task :run
Java 14.0.1
Sending request
<=========----> 75% EXECUTING [46s]
> :run
Response received:
[...]

I tested this sample code against google.com and it responds which indicates to me that it’s not the client code.

4. Error messages and/or full log output:

No errors or log entries from caddy, php, or client after making request.

5. What I already tried:

All other requests through caddy to php work fine.

I tried using wireshark between the client and the server to and get this request:

POST / HTTP/1.1
user-agent: Vert.x-WebClient/4.0.0
content-type: application/x-www-form-urlencoded
host: localhost:8088
transfer-encoding: chunked

1b
field1=value1&field2=value2
0

I tried attaching a breakpoint in PHP (and verified working xdebug beforehand) and no luck; the breakpoint is never hit.

6. Links to relevant resources:

The first few ways I was looking at it through wireshark I didnt see the chunk sizes but they were there; it resulted in this bug report with vertx but I was mistaken.
https://github.com/vert-x3/vertx-web/issues/1818

I don’t see root in your Caddyfile to specify where to read the files from, and I don’t see you mounting the code to both of your containers. There’s some pieces missing here. It also looks like you’re not persisting the /data volume from the Caddy container, which is important to avoid various issues.

I tried my best to clean things up (and retest); I omitted a bunch that would add pointless complexity to the content here; long story short, it downloads the files into the container at startup based on metadataand/or volume mounts.

I don’t believe the php/file config is the cause of the issue I’m reporting here as every other request through that PHP handler works fine; it’s just the chunked transfer that seems busted.

My understanding is the root is for serving files but the issue here is the php-fpm handler which doesn’t use files, no? I mean I don’t have the root and it works (except for this chunked transfer)

Honestly, any omissions just make it more confusing for those trying to help. Please don’t omit anything.

I don’t see any of that in what you posted. That is relevant.

The root needs to be set for Caddy to know where your PHP files exist on disk. It needs to see them to be able to correctly determine how to rewrite the request to send the fastcgi request to php-fpm. This is part of the try_files logic that is part of the php_fastcgi directive. See the expanded form here:

The root also needs to be set for file_server to know where to look for files as well.

By default, Caddy will assume root is your current-working-directory, which is /srv by default in the official docker image. But like I said, I see nothing in your post that would indicate that you’re mounting files to /srv, so I can only assume that you aren’t doing that.

1 Like

Here’s the missing startup script:

#!/bin/sh
# exit on error, exit on unknown variable, and exit on pipefail
set -eo pipefail

# Download the caddy config to  files to "$filePrefix/web"
addFile "$filePrefix/build/configs/turbokivaweb/migration.caddy"

# Download the PHP files to "$filePrefix/web"
addContents "web"

cd "$filePrefix/web"

echo "Caddy version $(caddy version)"
caddy run --watch --config "$filePrefix/build/configs/turbokivaweb/migration.caddy" --adapter caddyfile

Seems like the implicit root' for the current working directory coupled with the conclusion of the startup script cd` -ing to the path where the PHP files are is what gets things working (generally speaking)

PS:
The implementation of addContents reads from environment variables, google cloud metadata server, and optionally mounted volumes to figure out where to pull files from

This topic was automatically closed after 30 days. New replies are no longer allowed.