I feel like the advent of CFContent got rid of many of the needs to go directly into the response object to do things.
I'm doing this with cfcontent all the time, what's the benefit of "streaming" images instead? With cfcontent you block one of the listeners ("simultanious requests") while the image is being transferred to the client, is this perhaps different with the streaming example?
If I had the Maximum number of simultaneous requests set to 8 on my server and my site was streaming 8 images to users with a dialup connection that would clog the machine right? That problem wouldn't exist using the file system.
Whether you are writing to the Response object or using the CFContent tag, I *assume* that it still keeps the single thread busy with the binary data transfer. After all, something still needs to be flushing the response to the client.
I believe the only way to get around this is to pass of the file request to a static file server (I think something that Apache can do inherently, but not IIS).
I wonder if this would fix (and I should test it) the bug with serving up images that are virgin - ie - make from scratch with cfimage (as opposed ot reading in a real file). I know Jason Delmore had posted a fix for that a while ago.
I think the problem there is that on a CFImage-created binary, there is no "file type" until the image is saved. Therefore, I think there are problems streaming the underlying BLOB data because it has no particular encoding?? I am only guessing here, but I think that is the problem I have run into.
If that *is* the problem, I think you will still encounter the same issue - that no compression / file type is defined..... but totally guessing here :)
The difference between the code in the tech note and cfcontent is that with cfcontent the server sends Connection:close to the client, and with the code in the tech note, it sends Content-Length. I determined this with the HTTP-Headers plugin for firefox. I'm not sure I understand the difference, or why I might use one and not the other, but there it is.
I tested this with a very large image, and both techniques loaded the image in the same amount of time.
One of the servers I have access to has sandbox security turned on. cfcontent is not allowed, but cffile is allowed, and the code in the technote works on that server. So there's one advantage. If you're allowed to use cffile but not cfcontent, this is a workaround.
Good point re: security concerns. As for the content length, you can add that using CFheader: