I'm trying to figure out if it's possible to slow down the server when it's sending multipart/xmixed-replace responses. I want my client to try to rate limit a motion jpeg stream. I've found a lot of documentation about what the server sends in an HTTP response but nothing about what the client sends.
What does the client send, if anything, after each part in a multipart/x-mixed-replace response? If it doesn't send anything, does the server just keep piling on the parts?
Actually I think the multipart thing is a red herring because the concept of multipart is just to delineate content types within the same message body. So from a server perspective (in terms of the rate at which content is sent) it is not really different from sending a single big chunk of data.
So, I am wondering if you can the Range header to only request a specific range - one "part" at a time.
Start counting bytes from the end of the response headers. When you reach the end of the first part, note the number of bytes read and close the connection. Send a request for the same document but specify the starting Range as the bytes at the end of chunk. Again, read the response, when you reach the end of the part, add the current response bytes to the previous, close the connection and repeat ad nauseam...
Haven't tried it, but sounds like it would work provided the server supported range headers and provided you were able to do some patching on the client side.
Might be easier to write a client-side proxy that rate limits by dropping packets ...