Getting Files

How do we allow users to download ASP files without using FTP, especially since the server processes the ASP commands before we even get a chance to look at it? Well, fortunately, there's a little known HTML header that helps us do just that.

<%
dim fso, f, file, strPath, strName, intSize, strContent

strPath = "c:\inetpub\wwwroot\somefile.asp"

set fso = server.CreateObject("Scripting.FileSystemObject")
set f = fso.GetFile(strPath)
set file = fso.OpenTextFile(strPath)
strContent = file.readall
strName = f.name
strSize = f.size
f.close
file.close
set f = nothing
set file = nothing

Response.Buffer = true
Response.ContentType = "application/octet-stream"
Response.AddHeader "Content-Disposition", "attachment; Filename = " & strName
Response.AddHeader "Content-Length", intSize
Response.Write(strContent)
%>

The content disposition header instructs the browser to display a pop-up download box instead of just rendering the file. This allows the user to save it locally on their computer. Unfortunately, there are problems with how the different browsers handle this header, so we must supply a few other things as well, which I'll discuss in a moment.

First, we grab some necessary file info, such as the size, name, and actual content (Note: You would replace strPath here with the Location field from the database). We then turn on buffering so that all scripts are executed before anything gets rendered to the page.

With IE, if we just added the content disposition header, the file download will most likely fail. Therefore, we must instruct the browser that the content we're about to send it is of type application/octet-stream, or essentially, a binary file from the browser's point of view. Finally, we must write the content to the browser. Note that the content-length header is usually not necessary, but is a good precautionary tactic. Go ahead, try it out! You can now download any file from the server, and it doesn't even have to be in the internet root directory.

As soon as this script has been executed (and the user has downloaded the file), we can now flip the read-only attribute back. Voila, instant protection. When a user comes to look at this file again, you'll do a check to see whether or not the current user is the user who checked the file out. If it is, allow them to check it back in, if not, don't let them do anything with it. Also, with this method, users will have to use the source control application before modifying a file, because they won't be able to overwrite it otherwise.

The check-in procedure will work in nearly the same way. Display a list of the files to the user, allow them to select the ones to check in, clear the read-only flag, upload the file, and set the read-only flag once again (don't forget to update the LastModified field in that database as well). I won't go into detail here on how to re-upload the modified files, but check out this great article on how exactly to upload files.

Continuing On...
Effective Source Control
Additional Considerations