Classic ASP is still one of those old realities I have to deal with, and I found myself struggling with this snippet of code I found on MSDN. I installed the asp file (file.asp) into the root of an asp based web server and it simply would not work. File.asp was simply designed to display a page by insert the image as a binary stream into the http header.

<%@ Language=VBScript %>
Response.ContentType = "image/jpeg"
Set objHTTP = Server.CreateObject("Msxml2.ServerXMLHTTP")
' Point to an image file with adequate access permissions granted "GET", "https://" & Request.ServerVariables("SERVER_ADDRESS") & "/any/someimage.gif",false
Response.BinaryWrite objHTTP.ResponseBody
Set objHTTP = Nothing

Let me set the background, I was accessing the address of the server using https, and the certificate was valid and I was accessing it using the name on the cert (e.g https:\\

The problem with the above situation was that the server variable defined by Request.ServerVariables("SERVER_ADDRESS") was giving me back a valid ip address it just did not match the name in the certificate!

I updated the server variable to Request.ServerVariables("SERVER_NAME") and bingo!! SERVER_NAME is designed to invoke the name of the server, specifically, the official name that the cert uses. Pretty much everything else in an ASP web site will work even when the cert does not match. Binary streaming, however, is extremely sensitive to any security snafu.

I have included a partial list of the Request.ServerVariables for future reference:
ServerVariables Sample
("PATH_INFO") /test/examples/mystuff.asp
("SCRIPT_NAME") /test/examples/mystuff.asp
("URL") /test/examples/mystuff.asp
("HTTP_USER_AGENT") Mozilla/4.0 (compatible; MSIE 7.0; Windows T 5.1; Mozilla/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1)
("HTTP_UA_CPU") x86
("SERVER_SOFTWARE") Microsoft-IIS/5.0
("HTTP_ACCEPT_ENCODING") gzip, deflate