There is a tiny comment form service on this website to accept comments from visitors and save them on the file system of the web server for me to review later and publish. This form is the only thing on this website that is dynamic in nature. Everything else on this website is static. The little comment form has led me to an interesting curiosity. I sometimes see visitors submit a duplicate copy of their comment.

{{ toc }}

## Mysterious Copies

Most of this website is made of handcrafted HTML. The blog posts and other content files are handcrafted HTML pages. A Common Lisp program adds common headers and footers to these pages and generates the HTML pages that are served as static files via Nginx running on a Debian system. The comment form, however, is a dynamic web application served via another Common Lisp program that makes use of the Hunchentoot web server to serve the form, accept the input submitted by the user and then process it. This comment form is a very simple, minimal and stateless application that fulfills the modest requirements of this modest website pretty well.

However, often I see multiple copies of the same comment being saved on my web server. In the initial days of encountering this issue, I felt quite confused. I could rule out a bug in my program by carefully reviewing and testing it. Further, the web server logs clearly showed multiple POST requests being received by it from the same client usually with a few seconds of intervals between the consecutive requests. The comments seemed to have legitimate content. Since the duplicate copies would all have the same comment, I would arbitrarily pick one and publish it on my website. But I often wondered why on earth well meaning visitors would sometimes submit the same comment multiple times. For good measure? Perhaps! But still quite odd!

## So What's the Problem?

The mystery of duplicate comment submission remained a puzzle for several months. Then one day, one of the visitors to my website contacted me via Twitter messages to tell me that my comment form was broken and it was not working for them.

The conversation began like this: "Hey! The comment form on your website seems to be broken. It says it has accepted my comment but I don't think it is doing that."

I responded, 'Hi! Thank you for contacting me about this issue. What do you mean it does not accept your comment? Do you see an error?'

'There is no error. After submitting, I get a success message that says, "Comment was submitted successfully. It may be published after review."'

'That sounds about right. So what's the problem?'

In the meantime, I performed some testing at my end to find that the comment form appeared to be working fine with no apparent issues. Further, I found that there were multiple copies of their comment saved neatly on the server for me to review later and publish.

Before I could share my findings, they continued, 'Well! That success message appears almost instantly. It couldn't be storing my comment successfully that fast, could it?'

That is when the mystery unfolded for me! The issue was that the comment form accepts the user's comment and returns a success message too soon for the user to believe that it could have possibly saved the comment. I have had a couple of other very similar conversations since then when a visitor contacted me via email or another means to double-check if my comment form was really working fine. In all of these cases, they were skeptical about the success message because it appeared much sooner than they expected.

## Fast But Unsettling

Depending on where the visitor is located, the comment form on this website may take anywhere between 30 ms to 900 ms (and very rarely a little longer) to accept the user's comment, save it successfully and then display a success message to the user. However, a response that arrives within a few hundred milliseconds can sometimes feel a little too quick to be reassuring. I presume that many of us have become accustomed to visible signs of activity when submitting forms, so a web application that finishes its job in a few hundred milliseconds may not always provide enough time for that sense of confirmation to settle in.

I must clarify here that the duplicate comment submissions do not bother me at all. The duplicate comments I receive are a very small fraction of the total number of comments. I just find it interesting that a simple piece of software doing a simple thing quickly can sometimes leave a user wondering whether it really did its job. I had one visitor to my website even say, 'I really was expecting a spinning wheel on the browser tab or some sort of progress indicator to be assured that it is saving my comment. The instant success message took me by surprise!' They felt unsure that their comment had been saved and resubmitted the comment again.

## Conclusion

The thought of disabling the form or even showing a different page altogether has crossed my mind several times. In fact, an older version of this website, written in PHP, did have a comment form that showed a dedicated success page on submission. The case of duplicate comments still used to occur then. I am no user experience expert, but I do not usually like adding artificial features or restrictions merely to conform to modern web design conventions. As a user of the Web, I have often wondered why websites cannot leave the input form alone after successful comment submissions. I am not convinced the reasons are sufficient to introduce such artificial restrictions. This is my personal website. As much as visitors have certain expectations about how a comment form should behave, whatever solution is implemented should make me happy too. After all, it is my passion project that I work on out of love for computing and the Web! So I am leaving my comment form alone for now, since I am not sure what a good solution to this phenomenon is that suits my taste and preferences as well.

## Update #1

Update on 13 Mar 2022: Many commenters to this post have suggested that the issue here might not be the fast response of a successful comment application but instead the fact that the comment form elements remain intact even after the comment submission. In their opinion, merely displaying a success message may not be assuring enough. They further suggested that I should change the state of the form in some way on successful submission. Popular recommendations included disabling, clearing or removing the form elements entirely on successful submission.

These suggestions are valid of course. However, I also think that these suggestions reinforce the point of my blog post. Without these fancy features and restrictions, web surfers today feel unsure if the comment form application has really done what it is literally saying it has done.

Do I really need to consider artificially clearing, disabling or removing the form elements and thus removing the ability to edit a comment again and resubmit it (even if the user really so desires) with a single click of a button? What if someone wants to post another comment immediately after the first one? What if someone wants to edit their previous comment slightly and repost it? Do I need to force the user to hop through separate links and buttons to be able to do these simple tasks? 'But every other website clears, disables or removes the form elements', you might rightfully offer as a counterpoint. I know. I know. But why is it so that the 'right' user experience nowadays involves artifically encumbering the user or hiding the user's own submitted text from themselves?

In fact, in an earlier version of this website, the comment form application did disable the form elements on a successful comment submission. In an even older version of this website, a new page consisting only a success message appeared. However, visitors would still report their suspicion regarding the comment form doing its job to me. So I have observed the results of employing at least two of the measures suggested and they were still consistent with the reporters' claims that they find the instant success message from the application to be disconcerting.

UX best practices notwithstanding, I do not want to hide the users' content from themselves after a successful form submission. Maybe they want to copy the message and keep it for themselves. Maybe they want to edit it again and repost it. I do not want to restrict any of these simple activities. I also do not want the user to hop through an additional link or button to be able to do these things. However, heeding some of the other advice I have received in the comments section, I have now made two tiny changes to the comment form application that is consistent with its original spirit of simplicity, minimalism and statelessness:

- I have moved the success message to the top of the response page.
- I have also added additional text in the success message that explains that the submitted input has been left intact in case the submitter wants to copy it or edit it and resubmit it.

I hope these tiny updates will help reduce the incidence of duplicate comments. I will keep an eye on how the comment form is used over time and post another update later.

## Update #2

Update on 24 May 2026: Four years have passed since I last updated this post. It is time for another update. In Update #1, I shared that I had made two small adjustments to the comment form. The success message was moved to the top of the page and additional text was added to highlight that the comment text has been left intact and explain why. I am happy to report that, since those changes were made, there has not been a single occurrence of duplicate comment submission again!