Putting Packet Sniffers To Use
How long have I been going on about HTTP packet sniffing for now? At least two years! Anyhow, it's long enough to warrant me giving you an example of how useful they can be. This morning I was IMing with Erwin van Hunen. He's writing an article for us all on how to internationalise a web form. Part of this involves looking at the language that a browser tells a server it would prefer to use. Erwin seemed shocked that his browser wasn't specifying a language. He had a computed text area with the following formula
@GetHTTPHeader("HTTP_Accept_Language");What was even stranger was that if Erwin added a self-computed field called HTTP_Accept_Language, this worked. To see if my browser sent this value I launched IE and enabled the sniffer I mentioned last Thursday. After sending a request for a page, I switched to the Headers tab and looked at exactly what IE tells the server about me. As you can see from below there is indeed a language setting, with a value of en-gb.
However, notice the header name. It's Accept-Language and not HTTP_Accept_Language. I asked Erwin to try the following:
@GetHTTPHeader("Accept-Language");Guess what! Indeed - it worked. A nice little example of how knowing what's going on behind the scenes in the browser can help you understand what's going on at the server level. In this case it appears that the server translate the header in to the CGI field with a different name but the same value. Obviously it didn't provide the answer as such and there's a little logical thinking involved. See what I'm making the fuss about now?
Skip to the 
You can subscribe to an individual
Add your own non-standard field and try:
@SetHTTPHeader("Hey_look"; "Domino Powered")
I played with the SetHTTPHeader function once and just didn't get it. Where is meant to be used and for what purpose...
Try using it to cache/not cache your pages. I use this formula for all pages on my site.
REM {Applicable to R6+ only};
@If(CachePageYN="Yes";"";@Return(""));
datNow := @Now;
datMidnight := @Adjust(datNow;0;0;1;-@Hour(datNow);-@Minute(datNow);-@Second(datNow));
@SetHTTPHeader("Cache-Control"; "public");
@SetHTTPHeader("Expires"; datMidnight);
@SetHTTPHeader("Last-Modified"; @Modified);
Nice idea John. Where do you that? In the WebQueryOpen event?
Just put the code in a computed for display field on the form.
Try reading this:
{Link}
or some of the links in this page:
{Link}
See I do blog sometimes.
Thanks John. Might look in to setting headers a little more now. Maybe even an article. Shock horror...
actually it's Accept-Language and not Accept-Langauge ... ;)
Thanks Gaston. Always good to have a proof-reader. Corrected now....
huh. you got me poking around domino help, and i quite accidentally ran across this...
@FormLanguage
help says: The following formula returns "en-US' when used on a form designed in English(United States).
never seen that before...
thanks john for the info on the setheader thing. i was playing with that recently but hadn't worked out how to get it to do anything either. maybe because i was running the client version of the http stack (nhttp.exe)? not sure...
:-P
Very Nice John. Thanks for the tips and links! Too bad my client is still on R5...
If anyone can verify Jonvon's suspicion about nhttp.exe not supporting this, that would be helpful to know.
That sniffer rocks. I've found some interesting things I didn't know - like, when logging into a secure website, your password is still clear text in the packet... I did not know this. It shatters my naieve perception of web security.
If you use Mozilla you can get an extension/plug in called "Live Http headers" ( {Link} ) which does exactly what it says ! Very simple and ideal for spotting things like this.
It does not work with my client (nhttp.exe) stack either it must be server only thing.
Talking of little used @Formula after little DLL resource digging I found an at formula called
@AccountGetInfo(text;[text])
Dont have a clue what it does and its not documented as far as I can see. But sounds useful.
Jerry - I presume when you say "Secure Site" you mean SSL encrypted site. Your password is in cleartext in the packet, but the whole communications channel between your browser and the web server is encrypted with SSL. Even the URL string that is being sent to the webserver is sent across the encrypted channel. All that would show up in a proxy's logs is that you connected via SSL to "secure.example.com", but not what page(s) you requested, since the requests were encrypted between your browser and the server the proxy doesn't know.
Marcin,
Thanks... I thought it was too obviously bad to be true... but I feel better having some confirmation.