Add trace log for streaming files

src/server/file_server.rs

@@ -306,6 +306,9 @@ async fn serve_file (
 			let mut bytes_sent = 0;
 			let mut bytes_left = content_length;
 			
+			let mark_interval = 200_000;
+			let mut next_mark = mark_interval;
+			
 			loop {
 				let mut buffer = vec! [0u8; 65_536];
 				let bytes_read: u64 = f.read (&mut buffer).await.unwrap ().try_into ().unwrap ();
@@ -330,7 +333,10 @@ async fn serve_file (
 				}
 				
 				bytes_sent += bytes_read;
-				trace! ("Sent {} bytes", bytes_sent);
+				while next_mark <= bytes_sent {
+					trace! ("Sent {} bytes", next_mark);
+					next_mark += mark_interval;
+				}
 				
 				//delay_for (Duration::from_millis (50)).await;
 			}

todo.md

@@ -1,4 +1,5 @@
-- Not working behind Nginx (Works okay behind Caddy)
+- Add byte counter in `trace!()` macro in the file server
+- Not working great behind reverse proxies
 - Show file server names in HTML
 
 - Impl multi-range / multi-part byte serving
@@ -58,3 +59,16 @@ I tried to figure out the percent encoding and it didn't work.
 
 Maybe Base64 would be better or something? At least it's unambiguous and it
 can go straight from UTF-8 to bytes to ASCII-armored.
+
+## Turtle in Firefox's network debugger
+
+The turtle shows up if Firefox has to wait more than 500 ms till first byte.
+Curl says we can download a small file (950 bytes) end-to-end in about 250 ms.
+
+So I think somewhere between Firefox and Caddy, something is getting confused.
+Firefox, probably the same as Chromium, doesn't try to buffer entire videos
+at once, so I think it purposely hangs the download, and then I'm not sure
+what happens.
+
+I might have to build a client that imitates this behavior, since it's hard
+to control.