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.