More On Using Cookies With Domino

Today I was going to describe the symptoms of what I'm sure is a bug in Domino. The circumstances needed to reproduce it are too obscure though. It's not really worth the air time. Instead, here's the workaround solution I used.

Thanks to YoGi (I wish my French was better, as this looks like a good Domino blog) I learnt something new: you can create cookies from LotusScript. I assume we all know you can use the following code to take control of an Agent's HTML output:

Print "Content-Type:text/html"

So, it follows that we can use similar code at the start of an agent to set other headers. Like the header needed to create a Cookie:

Print "Set-Cookie: codestore_name=" + doc.Name(0) + "; 
expires=Friday, 11-Jan-2030 01:10:00 GMT; path=/;"

So, what happens on this site if I choose to store my details? Glad you asked. When you press the "Post It!" button the data you submit is POSTed to the URL "post?CreateDocument&ParentUNID=blogunid". The document is stored and the form's Web Query Save Agent runs. In here it uses some simple logic to decide whether to set Cookies. If you chose to store the details it sets three Cookies - name, email and website. If you chose to not remember the details and you previously had done it sets them all to "" and with an expiration date in the past (this is how you delete a Cookie). Otherwise it does nothing. Here's what the server sends back to the browser:

Next time you open a Blog (or any other page for that matter) on codestore the browser sends the server the following information:

The feedback form at the bottom can now be populated using the values you chose to store. To do this it uses some code Marcos Romero simplified for me. For example, the default value of the Name field is:

@Middle(HTTP_COOKIE; "codestore_name="; ";");

Each time you submit the form the same WQS logic happens. It has to. In case you change your name it needs to reset the Cookie values.

The only problem was that printing headers in WQS Agents means that full control is passed to the code and $$Return fields are ignored. Even the following code has no effect, it just prints the URL to the page:

Print "[/store.nsf/unid/BLOG-20050304?OpenDocument#post]"

I thought this made it a no-go solution, but, in a moment of inspiration I took the printing headers trick one step further and tried adding the following line at the end of the agent.

Print "Location: /store.nsf/unid/BLOG-20050304?OpenDocument#post"

It worked!

The Location header is what's used by Domino when $$Return fields do work. It sends the browser a HTTP Status of 302, which tells it the page has "temporarily moved" and the value of the Location header is where it now lives. Here's what it looks like in HTTPWatch:

Notice the first thing the browser does is POST the data to the server. On the left is a list of the headers sent to the server and on the right those received. The result from the server is a "302" that tells the browser where to go next. Hence the next thing we see is a GET request for the page, which results in a 200 code - "OK".

There you go. You learn something every day. A follow-up blog might be needed to explain the rudiments of using cookies and the values used, but that's all for now.


    • avatar
    • YoGi
    • Fri 4 Mar 2005 03:51

    Indeed, as "[URL]" redirections are 'normally' converted by Domino in HTTP headers, when you start printing your own HTTP headers,

    that mechanism doesn't work anymore. Thus, as you discovered it, you have to continue using your own HTTP headers ;)

    Anyway, be careful with cookies expiration and IE, it doesn't work well when your timezone is GMT+-something. I wrote something about it (in french ;) few days ago : {Link}

  1. Just a quick one :-

    If I remember correctly

    @Middle(HTTP_COOKIE; "codestore_name="; ";");

    Doesn't work in 100% of cases. Think boundary cases, and I think you need to expand the formula slightly.


  2. Thanks to both you & YoGi -- this is enormously helpful & I'm sure I'll be using it in the future.

  3. Jake,

    Have you tried [[url]] to redirect? (double square brackets). If I remember correctly, that will work.

    • avatar
    • Jake Howlett
    • Fri 4 Mar 2005 14:43

    Chris. Didn't try that. Can't see what difference it would make though. The idea of [[]] is that it avoids the redirect and returns the page straight to the browser. The fact that the headers are already tainted means that it doesn't work in this case, for the same reasons that [] doesn't work.

    I've not used that technique in over three years, since I wrote this article and found it too buggy. Maybe things have changed since then though...

    • avatar
    • Peter
    • Fri 4 Mar 2005 16:30


    You might want to take a look at this: {Link} It has all the insides of HTTP cookies, written by the cookie inventors, Netscape.

    You should also think about using @URLEncode when setting cookies, since people might throw in any kind of characters in the text used for the cookie, including ; and international characters. Use @URLDecode when reading the cookie in Domino.

    I've done this a couple of times, and it usually works better this way.


    • avatar
    • Jake Howlett
    • Fri 4 Mar 2005 17:07

    Good point Peter. I'd not thought of that. However, I can't use URLEncode in LotusScript though and I don't want to complicate the code with any Evaluate()s. I'll investigate alternatives but, for now, I think I'm happy in not "allowing" weird characters in these fields. Email and website are ok - they don't allow weirdness anyway. If you name needs a ; or a " then you need a new name! ;o) Although people with é in their name might complain. In search of fix right now...

    • avatar
    • Jake Howlett
    • Fri 4 Mar 2005 17:21

    OK, some simple test show that this is not a simple case of @URLEncoding and decoding submitted values. Domino is losing characters somewhere. I'll add it to the to-do list. In the mean time, people with names that include special characters will hopefully forgive me/Domino.

    • avatar
    • Jake Howlett
    • Fri 4 Mar 2005 17:50

    OK. More testing and I am more confused than ever. I don't want to go all out and call Domino black-n-blue, as I've done that before and been wrong. But I really think Domino is having issues here. I can't even work out what's going on back there. Oh, how I wish I were a PHP developer...

    • avatar
    • Peter
    • Sat 5 Mar 2005 01:39


    I really don't like Evaluate() in LotusScript, but have so far not found a better way to solve the problems with "weird" characters. There are not only the ; and " that could make it a problem though. My last name contains the character "■" (I'm from Sweden), and we also have the characters "■" and "■". Denmark has other "strange" characters, not to mention Island.

    I tried to write a pure LotusScript function for this, but with lots of character encoding schemes, it made for better performance to use Evaluate() with @URLEncode/@URLDecode instead.

    What do you mean with "losing characters"?


    • avatar
    • Peter
    • Sat 5 Mar 2005 01:40

    Wow, what happened with my swedish characters? What do you do to the posted text Jake?


    • avatar
    • Jake Howlett
    • Sat 5 Mar 2005 04:45

    Hmm, the plot thickens. I think it all boils down to the fact that this is a "fake" form. If you add a comment to this blog directly everything works ok.

    • avatar
    • Jaké
    • Sat 5 Mar 2005 04:46

    This was posted directly. Notice these characters åäö are ok!

    Anyway, it's Saturday morning and I'm damned if I'm going to waste it working out the nuances of Domino...

    • avatar
    • Jake Howlett
    • Sat 5 Mar 2005 06:12

    After an hour of wasted weekend I've realised it's not just Domino's fault after all. It seems the browser (both of them) send the form data differently for the "inline" and the "direct" form. For the inline form the "body" field looks something this:


    The direct form submits the data like this:


    In both cases the "e" in each word was an é

    Why the difference? I have no idea. One form seems to double-encode the text, while the other doesn't. IE and Firefox behave the same so I suspect they are following rules. I can't see what though. The inline form is not the only form on the page. Apart from that the pages seem identical.

    • avatar
    • Peter
    • Sun 6 Mar 2005 04:54

    In the inline form tag you have enctype="multipart/form-data", which I don't think you should use.

    From the HTML specification:

    enctype = content-type [p.53] [CI] [p.49]

    This attribute specifies the content type [p.247] used to submit the form to the server (when the value of method is "post"). The default value for this attribute is "application/x-www-form-urlencoded". The value "multipart/form-data" should be used in combination with the INPUT element, type="file".


    • avatar
    • Jake Howlett
    • Sun 6 Mar 2005 14:13

    I tried that Peter but it made no difference.

    • avatar
    • Peter
    • Mon 7 Mar 2005 00:02

    The only other difference I can see is that you don't have a name="xxx" in your form tag, but that shouldn't make a difference either.


    • avatar
    • Jake Howlett
    • Mon 7 Mar 2005 02:09

    I tried that too Peter. I must have tried everything. Something make me think it's going to be a very simply problem that's going to make me feel very stupid once I work it out ;o)

    • avatar
    • Peter
    • Mon 7 Mar 2005 03:48

    Well, I've tried but I can't recreate the problem. I've tried both the direct and indirect approach to submitting a new document, with different types of parameters, and swedish characters works every time. I don't get it...


    • avatar
    • James Jennett
    • Mon 7 Mar 2005 04:01

    Spent ages wrestling with this one back in 2001/2... I came off worst and knocked it on the head(er).

    Seems you have nearly cracked it though. Keep on!

  4. Jake,

    have you tried adding 'accept-charset="UTF"' to your form tag this may/may not help with the character problem.

    Tip-> {Link}

    • avatar
    • Jake Howlett
    • Mon 7 Mar 2005 11:48

    Thanks John. That seems to fix it, although I've not tested it properly yet.

    It seems odd having that as the charset to the form as it's different to that of the page. I don't fully "get" what's going on here yet and need to investigate more. I'll try and summarise the problem (if there is one) in blog form soon...

    • avatar
    • Jake Howlett
    • Mon 7 Mar 2005 12:02

    Hmm, I spoke to soon. IE 6 still doesn't like it. I might have to leave this until later. It's twisting me melon man.

    • avatar
    • Jake Howlett
    • Mon 7 Mar 2005 13:27

    Phewee! I found the solution: it's a server setting thing.

    I'll write a blog entry about it now as it might be quite interesting?

    • avatar
    • Claes
    • Thu 10 Mar 2005 04:43

    Hi! I've been struggling with exactly the same problem for a week...have you written the blog entry about the server setting?

    Thanks in advance!

    • avatar
    • Jake Howlett
    • Thu 10 Mar 2005 04:50

    Claes. The blog entry got too big and it's now a draft article. Almost finished!

    I'll emai you a rough-cut.

    • avatar
    • steve
    • Wed 23 Mar 2005 22:37

    thanks for all your help on Cookies - has come in really handy!

    • avatar
    • Alastair Grant
    • Thu 4 May 2006 06:12 AM

    if you have already aken control over the agent html output code and want to post a 'submitted message' before redirecting then You could write a meta tag to the page header as well.

    <meta http-equiv="refresh" content="2;url=Location: /store.nsf/unid/BLOG-20050304?OpenDocument#post">

  5. You rock! Writing a java agent for a mobile application was taking its toll on me. I couldn't use javaScript for redirection as either most mobiles don't have the feature enabled by default or don't have it at all. Well little did I know that I could use


    Once again.. thank you.

Your Comments


About This Page

Written by Jake Howlett on Fri 4 Mar 2005

Share This Page

# ( ) '


The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social

About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »


Here are the external links posted on the same day.

More links are available in the archive »

More Content