I dont know whether it’s a limitation of CGI, but in apache there was the nice feature where you could blast the output of PHP partway to the user, do more stuff and then output the rest.
I like to do this for example when I do a password validation, because strong hashes may take a while and it just looks better when the user sees that a login is happening rather thn looking at it being unresponsive.
this is the code I used. on a (sadly a bit older, updating that thing is a pain, contrary to caddy, but it’s only a localhost installation) XAMPP this runs nicely showing first the Please wait line, and the 5 seconds of sleep later (as a subsitute for actually doing stuff) it shows the finished line.
on caddy it just waits the time and then shows all at once.
is that a limitation of CGI, or caddy in total or is there a different way to solve this?
<?php
//Flush (send) the output buffer and turn off output buffering
while (@ob_end_flush());
// Implicitly flush the buffer(s)
ini_set('implicit_flush', true);
ob_implicit_flush(true);
header('Cache-Control: no-cache'); // recommended to prevent caching of event data.
flush();
echo ('stuff is loading Please Wait...<br><br>');
@ob_flush(); //force output to browser
flush();
// ---------------------------------> do stuff
sleep(5);
-----------------------> stuff is over
echo 'Finished!';
@ob_end_flush(); //end output buffer
flush(); //-> out everything yet again
I haven’t looked into your problem at all, but I wonder if it’s a similar problem to the one @Laszlo_Balogh was having in this post: Reverse proxy buffering
They have updated their post several times so it might be worth reading through that and seeing if any of their findings/solutions apply to you as well.
well the problem sure is similar, but his solution which (according to the last update) kicked gzip into oblivion, but made it work, didnt work for me (extecped this already because I explicitly removed gzip from the caddyfile already.
Your issue seems different than mine. I would suggest first figuring out where data is buffered. For that you could use WireShark or chrome://net-internals. It helped me a lot. If the data is buffered in the client side, you can try sending ‘X-Content-Type-Options’ header with the value of ‘nosniff’. If it is buffered on Caddy’s side, just ‘go get’ Caddy from github and put in a few print statements.
Also, is the connection HTTP/1.1? If it is, has the Transfer-Encoding header been sent with value of ‘chunked’?
I am not sure whether it is using h2 or http1.1 but since I am using https I am pretty sure it uses h2, is there a way to force http1 on HTTPS?
but the weird thing is that even on plaintext HTTP (which is HTTP1 as iirc all the browsers use h2 only on HTTPS) caddy goes around and fails with a 502 bad gateway when I insert the header using PHP, and it gets completely ignored when adding it via header in the caddyfile.
This is the section of the fastcgi directive where you can see a variable resp is initialized to hold the response body, filled with data from the fcgiBackend, and then copied to w (the http.ResponseWriter).
As a general rule, you can expect that a directive will always do its response writing within a function named ServeHTTP, which is required to satisfy Caddy’s Handler interface to be valid middleware.