All ServerVariables

[whammy]

Since a lot of questions have been asked about ServerVariables, here's a nice little script that loops through the collection and also writes their value to the page:


<%
Dim Item
For Each Item in Request.ServerVariables
Response.Write(Item & " = " & Request.ServerVariables(Item) & "<br />" & vbCrLf)
Next
%>


And here's the list:


Request.ServerVariables("ALL_HTTP")
Request.ServerVariables("ALL_RAW")
Request.ServerVariables("APPL_MD_PATH")
Request.ServerVariables("APPL_PHYSICAL_PATH")
Request.ServerVariables("AUTH_PASSWORD")
Request.ServerVariables("AUTH_TYPE")
Request.ServerVariables("AUTH_USER")
Request.ServerVariables("CERT_COOKIE")
Request.ServerVariables("CERT_FLAGS")
Request.ServerVariables("CERT_ISSUER")
Request.ServerVariables("CERT_KEYSIZE")
Request.ServerVariables("CERT_SECRETKEYSIZE")
Request.ServerVariables("CERT_SERIALNUMBER")
Request.ServerVariables("CERT_SERVER_ISSUER")
Request.ServerVariables("CERT_SERVER_SUBJECT")
Request.ServerVariables("CERT_SUBJECT")
Request.ServerVariables("CONTENT_LENGTH")
Request.ServerVariables("CONTENT_TYPE")
Request.ServerVariables("GATEWAY_INTERFACE")
Request.ServerVariables("HTTPS")
Request.ServerVariables("HTTPS_KEYSIZE")
Request.ServerVariables("HTTPS_SECRETKEYSIZE")
Request.ServerVariables("HTTPS_SERVER_ISSUER")
Request.ServerVariables("HTTPS_SERVER_SUBJECT")
Request.ServerVariables("INSTANCE_ID")
Request.ServerVariables("INSTANCE_META_PATH")
Request.ServerVariables("LOCAL_ADDR")
Request.ServerVariables("LOGON_USER")
Request.ServerVariables("PATH_INFO")
Request.ServerVariables("PATH_TRANSLATED")
Request.ServerVariables("QUERY_STRING")
Request.ServerVariables("REMOTE_ADDR")
Request.ServerVariables("REMOTE_HOST")
Request.ServerVariables("REMOTE_USER")
Request.ServerVariables("REQUEST_METHOD")
Request.ServerVariables("SCRIPT_NAME")
Request.ServerVariables("SERVER_NAME")
Request.ServerVariables("SERVER_PORT")
Request.ServerVariables("SERVER_PORT_SECURE")
Request.ServerVariables("SERVER_PROTOCOL")
Request.ServerVariables("SERVER_SOFTWARE")
Request.ServerVariables("URL")
Request.ServerVariables("HTTP_ACCEPT")
Request.ServerVariables("HTTP_ACCEPT_LANGUAGE")
Request.ServerVariables("HTTP_CONNECTION")
Request.ServerVariables("HTTP_HOST")
Request.ServerVariables("HTTP_USER_AGENT")
Request.ServerVariables("HTTP_COOKIE")
Request.ServerVariables("HTTP_ACCEPT_ENCODING")

[whammy]

P.S. Thanks to oracleguy, notice that HTTP_REFERER is missing from the collection. That is apparently a MS oversight, or it isn't listed because it has no value (haven't tested that yet, but that doesn't make sense since a lot of empty values show up in this loop)...

I'm not sure what other variables are, but I'll keep this open to see. Please do not post unrelated comments in this thread or I will delete your post without prejudice. :)

[glenngv]

after testing, I conclude the following:

- HTTP_REFERER only shows up in the ServerVariables collection when it is NOT empty.
- The source URL where the redirection occurs must be ONLINE to show up referer in the collection.

The referer shows up in between HTTP_HOST and HTTP_USER_AGENT:
HTTP_HOST =
HTTP_REFERER =
HTTP_USER_AGENT =

[Morgoth]

That is odd, because there are alot of empty spaces in there, and alot of those veriables are not equaling anything.
Seems alittle funny to me.
Maybe we are missing many other veriables then!?!

[Roy Sinclair]

Some of those variables are added by IIS and which of those variables you'll see is also dependant upon the version of IIS you're using. ISAPI filters can also add or remove items so there's another place where things can change.

The real key is to remember the code Whammy posted at the beginning, put it into an include file and you can add it to a page you're developing when you're looking to see what's available and then remove it when you've found what you need.

[Morgoth]

Tis what I did.

[Mhtml]

Just a note, it would be better for people to use the script that lists the server variables which ARE AVAILABLE, because not all of those that Whammy has listed will function on all servers.

So, just have a page in your root with that script and use it before you use a server variable in your script.

Sorry Roy, didn't see your post mentioning using an include.

[oracleguy]

Guess what, I found another server variable!

NUMBER_OF_PROCESSORS

It should be self explanatory; it returns the number of cpus in the server.

I don't know when you'd actually use it but hey, it is kinda cool.

[oracleguy]

I found 3 more variables.

OS
windir
temp

It interesting that these return a value yet, they aren't listed when you run a for loop like what whammy posted eariler in this thread.

[Morgoth]

Neat, they do work.

<%=Request.ServerVariables("OS")%>
<%=Request.ServerVariables("WINDIR")%>
<%=Request.ServerVariables("TEMP")%>

[Roy Sinclair]

Interesting. I did a little additional checking and found that some but not all of the system environmental variables (set using the System Applet of the Control Panel and easily displayed by typing "set" into a command prompt) are accessible via the Request.ServerVariables construct. It looks like they exclude a specific subset of the variables since you can get the value of non-MS additions while others like "ComSpec" come back empty.

Now I'm wondering if this is a good thing, a bad thing or simply another thing someone at MS added but never documented.

[Morgoth]

Well, if it's only for the administrator to run then something like that is fine. Wouldn't you say so?
If MS didn't document it, someone else might of.

[oracleguy]

Yeah roy I noticed that too. And i tested it using the set command in the cmd prompt. If you set a custom one, it doesn't work via ASP.

It must be that it returns only some system variables that some MS programmer thought people could use.

Perhaps like the temp one is so if you needed a place to write temp files for your ASP app?

[Morgoth]

Originally posted by oracleguy
Perhaps like the temp one is so if you needed a place to write temp files for your ASP app?

That makes alot of sence, but just as much as changing functions made by MS for ASP, I bet you, there is a way to customize it somehow, as long as you can get the information some how.

(I am not sure about the function thing, but it make sence that there is a place where I could decode them and edit them, there just has to be.)
ASP.dll maybe?

[Roy Sinclair]

Originally posted by oracleguy
Yeah roy I noticed that too. And i tested it using the set command in the cmd prompt. If you set a custom one, it doesn't work via ASP.

It must be that it returns only some system variables that some MS programmer thought people could use.

Perhaps like the temp one is so if you needed a place to write temp files for your ASP app?

Temp variables set via a command prompt are LOCAL to the environment of the command prompt where they were set and are not global to the whole system. When the command prompt is closed they cease to exist entirely. That's why you didn't see one set that way. If you set one using the SYSTEM applet of the Control Panel it will be global and will show in all environments and those custom environment variables will be readable by ASP.

[Morgoth]

Roy, so does that mean I can globaly set a new variable?

[Roy Sinclair]

Originally posted by Morgoth
Roy, so does that mean I can globaly set a new variable?

Definitely.

[Morgoth]

Excellent, now I have two tasks.
ONE, find out how to set the variable, and TWO, find out what I can set that I need.

Looks to me, like I don't really need to set anything important just yet!

[Morgoth]

I just got bored while looking at this list I have, and I decided to play around with it. I made it look better, and your able to add new variables if you find them.


<html>
<head>
<title>Request.ServerVariables</title>
<style type="text/css">
table {background-color: #000000;}
td {background-color: #FFFFFF;}
</style>
</head>
<body>
<table cellpadding="2" cellspacing="1">
<%
Dim Item
For Each Item in Request.ServerVariables
Response.Write(" <tr>"& vbCrLf)
Response.Write(" <td>Request.ServerVariables(""" & Item & """)</td>"& vbCrLf)
Response.Write(" <td>" & Request.ServerVariables(Item) & "</td>"& vbCrLf)
Response.Write(" </tr>"& vbCrLf)
Next
Dim Items(5)
Items(0) = "HTTP_ACCEPT_ENCODING"
Items(1) = "NUMBER_OF_PROCESSORS"
Items(2) = "HTTP_REFERER"
Items(3) = "OS"
Items(4) = "WINDIR"
Items(5) = "TEMP"
For I = 0 to 5
Response.Write(" <tr>"& vbCrLf)
Response.Write(" <td>Request.ServerVariables(""" & Items(I) & """)</td>"& vbCrLf)
Response.Write(" <td>" & Request.ServerVariables(Items(I)) & "</td>"& vbCrLf)
Response.Write(" </tr>"& vbCrLf)
Next
%>
</table>
</body>
</html>

[oracleguy]

Hey cool.

The only thing I'd change is made the "For I=0 to 5" line, "For I=0 to UBound(Items)"

Because then you wouldn't have to change it if you added more variables to the array. But it doesn't make much of a difference.

[Morgoth]

UBound()

THAT'S WHAT IT WAS!

[Mhtml]

Ubound is UPPER BOUNDARY, in this it can be used to get the last entry in an array if you don't know how many items are in it.

For example, say you split up a string you would need to know how many items are in the array.


String = "This is my string!"
myArray = split(String, " ")

for i = 0 to Ubound(myArray)
print myArray(i)
next


Of course you can also use LBound or LOWER BOUNDARY as you may have guessed. :)

[Morgoth]

Well, I found 2 working variables:
Request.ServerVariables("TMP") Same as TEMP.
And
Request.ServerVariables("Os2LibPath")

I also found a few others that have information in them, but they don't seem to be comming up for me, maybe you?
There are at the bottom on the list:
http://24.226.62.28/-/sv.asp

I also found out how to make my own, but I am not going to bother to try, for I might break something. ;)

[whammy]

Yeah there is some unexplored territory here, apparently; or at least territory that I haven't explored yet!

I have seen in IIS that you can create custom HTTP headers, but I've never had a use for them, and I'm not sure what they're really for; I'm thinking perhaps you could use this for security, however I've also seen many posts saying that HTTP headers can be spoofed, although I'm not quite sure how one would go about doing that.

This really isn't my area of expertise, but I'd like to learn more about it.

What are your thoughts on this? Is there a way you could create custom HTTP headers that could be used for security, perhaps in combination with something else? Or are they intended for another purpose entirely? :)

[M@rco]

You can spoof headers going to the client easily enough by using the Response.AddHeader method from ASP.

The client can also spoof any header going to the server in exactly the same way, although this can't be done with a simple hyperlink. However, it CAN be done easily (in IE and ASP) by using the XMLHTTP/ServerXMLHTTP objects to make the remote HTTP request.

As for whether it's useful or not... well, unless you're up to no good, then not.

:p

[whammy]

Hmm, then what do you suppose that's for in IIS?

[M@rco]

The server can't exploit the client, but the other way round is common enough. Damn hackers! :p

However, the ability to set headers in IIS is useful for things like dynamic download scripts (http://www.sitepointforums.com/showthread.php?postid=492934)...

I am currently enhancing that script to allow download managers to resume downloads, which is achieved by manipulating the "Accept-Ranges", "Content-Length", and "Content-Range" headers. To see how it's done, simply view the HTTP traffic generated by your chosen DL manager (most show the info in a log window somewhere). Failing that, use a packet sniffer. Or get a better DL manager!! lol

;)

[M@rco]

I thought I should clarify that the Request.ServerVariables collection is a bit of a misnomer - it does not only contain server variables (i.e. configuration info), it also includes the HTTP headers sent by the client. Thus, if you use a download manager to download a test page which displays all ServerVariables (such as that posted by Whammy right at the start), you will probably find that it displays a few new ones, relating to data transfer info, resuming, etc.

This is also explains why people often get confused when they can't retrueve a value for a particular server variable - "HTTP_UA_PIXELS" is a classic example, which is rarely seen because it's only sent by very old IE clients (v2/3 I think)!

Here endeth this evening's sermon. Amen.

I shalt now goeth to bed.

[whammy]

That makes sense... I had gleaned that the servervariables collection also contained http headers sent by the client, but only if they were present - that much I think a bunch of us have figured out, because of such things as Request.ServerVariables("HTTP_REFERER"), for instance.

However, I'm still confused about the use of custom HTTP headers, unless they ARE used for stuff like a download manager, etc.

I guess my unfamiliarity with this subject is going to require some further study. :p

It's too bad I don't really have time right now... :(

[M@rco]

I'm confused by your confusion...!

Since it's part of the HTTP specifications that the server (and client) may issue a multitude of standard headers (as well as custom ones), it is important that any server-side scripting environment allows you to do so. Whether you yourself as a developer will actually use that feature is another matter, but it's vital that it's there.

At the very least, I'm sure you use Response.ContentType every now and again... this is a rather superfluous property, since assigning a value to it is identical to doing a .AddHeader("Content-Type", value), and is precisely what happens behind the scenes, and so you *are* in actual fact (indirectly) calling .AddHeader(). The only difference between the two is that because Response.ContentType is implemented as a property you can also read back the value you set (it is stored during the call), whereas once you've added a header directly through .AddHeader() you can't read it back, there is no equivalent .GetHeader() method.

I've never needed to read it back myself, but it's there if you need it. Which is precisely my point.

;)

[Morgoth]

I don't know about headers much, but from what I have heard here, and other places, in my attemps at learning asp, I have found that HTTPHeaders are unsafe to store information in, because it is easily hackable. Is this true?
Why use headers if a user can just take information out of them randomly?

And the big question I have is, what is the point of headers, what's it used for? Storing global variables?
All I know is that most of the HTTPHeaders store information about my computer, and get information from the user, like "refferal".

[M@rco]

You don't "store" info in the headers, you use them to communicate information relating to the HTTP transfer taking place. As it should be clear from above, it is easy enough to set any header to anything you want, and thus you (i.e. your ASP scripts) shouldn't trust the contents of the headers sent by the client, but that doesn't mean they're not useful and usable 99% of the time.

I don't see how I can make HTTP headers any clearer - I have already explained them in this thread... perhaps you should re-read my posts again. If there's something in particular that you don't understand, then I will try to explain it to you.

[whammy]

Yeah all of that seems fairly useless to me right now... I'm sure I may have a use for it in the future, and I know how to do it with script anyway; I thought perhaps I was missing an implentation of something cool in IIS on the server-side.

Who knows, I'll have to mess around with it more someday. But I try to devote any spare time I have (LOL!) to learning .NET.

Obviously HTTP headers are useful there too, but I was just curious as to why IIS offers custom HTTP headers itself - not how you might use them in scripting. Seems kind of redundant to me. :)

[Morgoth]

I am going to stick with whammy's answer and just say I don't have time for this.

Anything I need from the HTTP headers are just basic informationf or logging, and don't effect how my web site runs at all.

[whammy]

Yeah I'm not being lazy or anything, just kind of curious as to why these features are offered in IIS, although you can do the same thing with an ASP script. Perhaps there's something we're all missing here?

This kind of thing just piques my curiousity a bit... and apparently m@rco isn't getting where I'm coming from regarding IIS... but I'm used to that as well (people not getting the angle or somesuch). :p

[M@rco]

Originally posted by whammy
Yeah I'm not being lazy or anything, just kind of curious as to why these features are offered in IIS, although you can do the same thing with an ASP script. Perhaps there's something we're all missing here?

This kind of thing just piques my curiousity a bit... and apparently m@rco isn't getting where I'm coming from regarding IIS... but I'm used to that as well (people not getting the angle or somesuch). :p Ok, I get you. The point of offering custom headers within the IIS site properties is that it allows you to easily add headers to every served resource (i.e. pages + images + everything else) in one go. Any HTTP-EQUIV META tag can be reproduced this way, and thus it is useful for adding language information, cache control info, and other stuff. Adding this info to images/pdfs/etc via script alone would require a dynamic download script, which increases server load. Therefore, since they also have the further advantage of being easy to add/delete (instead of modifying source code, which you shouldn't let server admins do), it's better all-round if you use custom headers in IIS where possible.

Happy now? :p :D

[whammy]

Well yeah... that makes sense. :p

Haven't had a need to do that yet, but it's nice to have some idea what they should be used for in IIS. :)

[M@rco]

Hope I've enlightened you a little! ;)

[whammy]

Well with m@rco around, we'll soon know everything. :p

P.S. That is in jest. ;)

[M@rco]

:D lol ;)

[Morgoth]

I am so glad we cleared that all up.

Now it's time for me to take a bath...

Page #3