Ein Proxy kennt kein NPH

[pl]

… und der Payload ist interessanter Weise kürzer als die angegebenen 30 Byte:

Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 30

Ja. Der Proxy war das. Der hat, hier widersinnig (weil mit größerem Ergebnis), den Content "gepackt". Schau mal, falls Du den verwaltest, in dessen Manual nach ob man das Packen unterhalb von 1k verbieten kann: Bringt dann faktisch nichts.

Deswegen ja ein NPH Script. Ein solches übern Proxy zu requesten ist völliger Blödsinn. Im Übrigen gibt es zum NTP praktisch gar keinen Unterschied in Sachen Performance. Natürlich auch nur wenn man einen minimalen HTTP Client darauf ansetzt:

my $so = IO::Socket::INET->new("rolfrost.de:80") or die $@;
$so->print("GET /cgi-bin/nph-time.cgi HTTP/1.0\nHost: rolfrost.de\n\n");
my $res = do{ local $/ = undef; <$so>};
my $t = [unpack "C19N", $res]; # Genau 23 Bytes hat die Response
my $gmt = [gmtime($t->[19])];  # Zeitstempel in den letzten 4 Bytes

und auch hier siehst Du den Vorteil von NPH: Die gesamte Response lässt sich damit bytegenau zusammenstellen und damit auch bytegenau dekodieren. Eben weil der Webserver die ungeparst durchreicht. Ein Proxy hingegen weiß ja gar nicht daß es ein NPH Script ist, der parst das und hängt eigene Header an.

MFG

PS: Bei 4 Bytes im Message Body gibt es nichts zu packen. Das ist schon gepackt. Im Übrigen wird HTTP/1.0 verwendet. Da gibt es gar keine Komprimierung die kam erst mit HTTP/1.1