We should all know of the following three uses of the Print statement in web agents by now:
You can perform a HTTP 302 redirect (effectively replacing the $$Return field) with a line of code like this:
Print "Location: /"+web.path+"/thanks?ReadForm"
You can change the content type of the page (allowing you to create the whole HTML yourself) by using the following print statement before any others in the code:
Print "Content-Type: text/html"
Also that you can set cookies using a similar piece of code.
Print "Set-Cookie: style=red; expires=Friday, 11-Jan-2030 01:10:00 GMT; path=/;"
What I never knew — which now seems a logical progression of the above — is that you can use the Print statement to set any header you like, whether it's a valid header or not. For example, the following line works:
Print "foo: bar"
As do other valid ones, which let you over-ride values, like so:
Print "Server: jakester v0.999999999"
Whether this is useful or not it's definitely worth knowing about. Why? Well imagine you've written some code like this, which is pretty much what I'd done when I discovered this behaviour:
Sub Initialize On Error Goto ErrorProcess 'Error producing code goes here ExitProcess: Exit Sub ErrorProcess: Print "Error: " + Error Resume ExitProcess End Sub
Expecting an error message to help me debug the code I was working on, imagine my confusion when I saw nothing but a blank page — suggesting there was in fact no error when I knew there was. If I'd checked the headers to this blank page I would have seen the error in there.
It seems that using the Print statement to send a word with no white-space, followed by a colon, followed by a space and then a string will send the browser a header param/value pair (as long as no other Print statements were used before it). No matter whether the word you use before the colon is a valid header name or not. Maybe this is something all web servers do? I don't know. Either way, it's something you ought to know about!
Armed with this knowledge you now know not to expect to see it actually appear on the page. This could in fact be beneficial! You can now debug without the user knowing by sending "invisible" data back the browser and then using a sniffer like HTTPWatch to see this "hidden" information.