Ich habe ein sehr merkwürdiges Verhalten mit Traefik (1.3.5) in kubernetes (als Ingress (mit dem stabilen Diagramm verwendet)) verwendet.Traefik den HTTP-Status neu schreiben?
Ich habe einen PHP-Endpunkt hinter einem Lack-Server, der eine 404 zurückgibt, wenn ich es ohne besonderen Trick direkt kräuseln.
$ curl -v ingress.../sport/?page=404
> GET /sport/?page=404 HTTP/1.1
> Host: varnish.ingress.xxx
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Age: 0
< Cache-Control: max-age=10, public
< Content-Type: text/html; charset=UTF-8
< Date: Wed, 06 Sep 2017 21:19:48 GMT
< Server: nginx
< Vary: Accept-Encoding
< Vary: Accept-Encoding
< Via: 1.1 varnish-v4
< X-Cache: MISS
< X-Powered-By: PHP/7.1.6
< X-Varnish: 65773
< Transfer-Encoding: chunked
<
Das ist das erwartete Verhalten, aber wenn ich es durch traefik mit den gzip-Header (oder mit --compressed) locken, ich habe eine HTTP-200 ...: up_side_down:
$ curl -v ...ingress.../sport/?page=404
> GET /sport/?page=404 HTTP/1.1
> Host: varnish.ingress.xxx
> User-Agent: curl/7.43.0
> Accept: */*
> Accept-Encoding: gzip
>
< HTTP/1.1 200 OK
< Age: 0
< Cache-Control: max-age=10, public
< Content-Encoding: gzip
< Content-Type: text/html; charset=UTF-8
< Date: Wed, 06 Sep 2017 21:18:38 GMT
< Server: nginx
< Vary: Accept-Encoding
< Vary: Accept-Encoding
< Via: 1.1 varnish-v4
< X-Cache: MISS
< X-Powered-By: PHP/7.1.6
< X-Varnish: 197657
< Transfer-Encoding: chunked
<
Wenn ich den gleichen Test durch direkt auf Lack oder durch eine Amazon-Elbe mache, habe ich das Problem nicht und bekomme immer ein 404 ...
Ich bemerkte, dass Traefik den Vary: Accept-Encoding Header wieder hinzufügt.
Ich bemerkte auch Dutzende von server.go:2753: http: multiple response.WriteHeader calls Protokollmeldungen.
Hat jemand von euch schon dieses merkwürdige Verhalten? Irgendwelche Hinweise, wie zu untersuchen?
Vielen Dank im Voraus