[Looking for Charlie's main web site?]

Posting a form to itself without trickery, using an empty ACTION attribute

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Did you know that if a form has an empty ACTION attribute (or none at all), it will post back to itself (to the page that presented the form)? This can be very useful, and it's a lot easier than more complicated code that struggles to build the ACTION attribute to hold the current filename and any query string.

In the first iteration of this entry, I referred to the two approaches of either providing an empty ACTION or none at all, but as the comments below show, the former violates the HTML spec. So let's stick with the notion of an empty ACTION. Same result, though.

How often have we all seen code along the lines of:

<form action="<cfoutput>#cgi.script_name#?#cgi.query_string#</cfoutput>" method="post">

or more involved:

<cfset action=CGI.SCRIPT_NAME>
   <cfset action=action & "?" & xmlformat(CGI.QUERY_STRING)>
<form action="<cfoutput>#action#</cfoutput>" method="post">

All this could be replaced very simply with:

<form method="post" action="">

The form will post back to itself. I'll offer another post that shows a unique way to take advantage of this. In any case, I hope that this observation may help some folks.

(Update: I never got around to that other entry in 2007, but see a my reply to a comment below where someone asked for more info on the idea I had in mind.

Is this reliable?

Now, there are some who will argue that this is a violation of the HTTP HTML spec, and so it may be, but I've never found a browser in which it didn't work.

Again, a clarification over what I wrote originallyhere. As was refined in the comments below, it's a violation to have *no* ACTION, but it's perfectly legit according to the URI spec (section 4.2 at http://www.ietf.org/rfc/rfc2396.txt) to have an empty ACTION, which is interpreted as a "same-document reference. (Thanks, Christopher Bradford, for that info.) Given that, even the following cautions seem needless, but I'll leave them for any still concerned.

If you have any hesitation, because you have to support multiple browsers and you can't test all possibilities, I'll understand if you choose to pass on this. But certainly if you only need to support browsers you can test, then if it works as expected, enjoy.

If anyone reading this can offer where this is the case, I'd appreciate hearing it. If you want some simple code to test, try this:

<form method="post" action="">
   <input type="Submit">
<cfif cgi.request_method is "post">
   Posted to itself

If it shows the text within the IF, then it worked as expected.

What about query string info?

You may wonder about the earlier more involved examples that showed passing the query string, in case any had been passed to the form. No problem. This technique passes any query string along just fine. Try it yourself (add ?test=test to the form and view in the debugging info that it's still in the URL scope after submission.)

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
I can think of a few reasons for not going this route:

Knowing it is a violation of the HTTP spec alone is enough for me to not use this technique. While it may work on every browser today, it may not work on IE 8 or FF 3 if they decide to be more standards compliant. I really do not want to fix countless forms in the future.

The next developer that comes along may not have read this blog post, and wastes his time trying to figure out where the form posts to. ( "I just searched through 3 embedded js files and still don't see where the form posts to!")

Adding cgi.script_name?cgi.query_string is trivial.
# Posted By Gus | 1/2/07 9:10 PM
I'll add that, for those who aren't aware, a CFFORM with no method defaults to post and a CFFORM with no action not only posts to itself but does in fact pass the query string (URL variables) to itself again ;)
Well, Gus, before throwing the baby out with the bathwater ("it violates the spec so I won't use it"), I'd like to challenge any who argue that it does to point out how it does. I was only reiterating what I've heard some argue. I haven't seen the conclusive evidence.

And even if someone found it, I'd think it would still have to be evaluated against similar "against the spec" features that we may all use. I mean, we can be purist about it, but if someone could show that there are other similar "anti-spec" things that are widely used (and that we might ourselves use) then I would think that mitigates the concern for purity. But to each his own, of course.
# Posted By Charlie Arehart | 1/3/07 10:45 AM
Thanks, Simon, for your observation about CFFORM. I do want to point out something pertinent to this discussion however. In 6.1, such a CFFORM (without an ACTION or METHOD) does indeed build the kind of no-action form I discuss here. As of 7 (at least in the 7.02 I'm testing) I see that it does build the ACTION with both the filename and any querystring.

I suppose one may argue that they did this in response to the very concern that Gus has raised. If anyone at Adobe happens to be reading this and can report why it was changed that could help the argument (though the simple fact that CFFORM now does it isn't enough motivation in and of itself for me to argue against the no-action approach). Again, just my opinion.
# Posted By Charlie Arehart | 1/3/07 10:49 AM
Oh, and let me add something in response to Gus. You say "Adding cgi.script_name?cgi.query_string is trivial", and that's true, but I should have mentioned that was motivated to write all this by a discussion on a mailing list where someone was finding that the cgi.script_name value was coming up with an unexpected string being prepended to it that made the form submission fail. I recommended to him this no-action approach, and it solved the problem for him, so I decided to blog about the approach in general, but just forgot to mention that it was addressing a challenge with his script_name value (since he's not yet resolved why it was providing an incorrect value).
# Posted By Charlie Arehart | 1/3/07 10:52 AM

According to the HTML 4 spec Section 17.3 the Acction is a required attribute of the form element:

Having said that, I think there are myriad reasons to ignore the specs, I just think eliminating a form action is not a very good reason to do so as it is so easy to comply with the spec. Most of the time when the spec is ignored it is due to poor or non-compliance to the spec by browsers, thus workarounds are used. This is different than the case being discussed.

There are exceptions to every rule, but as a rule I would continue to recommend providing an action to html forms.
# Posted By Gus | 1/3/07 12:49 PM
How could this be a violation of the HTTP spec? HTTP isn't involved at this point; just HTML (and while it is a violation of the HTML spec to *omit* the action attribute, it can be an empty string with the same result). The *browser* is the entity that translates an empty action into the request, and the browser is making a valid HTTP request. So there is no violation of a spec. In fact, the URI syntax explicitly specifies:

4.2. Same-document References

A URI reference that does not contain a URI is a reference to the
current document. In other words, an empty URI reference within a
document is interpreted as a reference to the start of that document,
and a reference containing only a fragment identifier is a reference
to the identified fragment of that document. Traversal of such a
reference should not result in an additional retrieval action.
However, if the URI reference occurs in a context that is always
intended to result in a new request, as in the case of HTML's FORM
element, then an empty URI reference represents the base URI of the
current document and should be replaced by that URI when transformed
into a request.

It seems that this is reliable, consistent, and standards-compliant behavior.
I'd recommend you never do:

<form action="<cfoutput>#cgi.script_name#?#cgi.query_string#</cfoutput>" method="post">

You must check cgi.query_string doesn't contain <script> tags or whatever else XSS you can think of...

I use replace(cgi.query_string,"<","","ALL") in the blogCFC on my site..
# Posted By Geoff | 1/3/07 1:06 PM
Gus, thanks for your offer to the link in the HTML spec.

Christopher, thanks for your clarification that I misspoke in saying some had called it a violation of the HTTP spec. As Gus showed, the HTML spec says it should be there.

But you make a great point that if CAN be there and be empty. In case anyone would ask, what's the URL for that? I tried to find it but could not readily.

So it seems that while one could argue that you should not leave it off, you can leave it with an empty value (which I said, but did not show, in the blog entry). That's a fine clarification.

Finally, Geoff, you, too, make a great point. In fact, I was going to offer code that did address that, doing an xmlformat(cgi.query_string) but decided to leave it out as I was arguing that the querystring appending was unneeded. But yes, if one does leave it, then it's wise to consider security concerns.

(Indeed, this argues yet another reason to just leave it blank and leave it to the browser to pass along whatever is sent. As for whether the ultimate action page should further validate the input URL variables for potentially bad data, that's an entirely different subject that I'd rather not open for discussion in this comments of this blog entry.)
# Posted By Charlie Arehart | 1/3/07 1:21 PM
Here's the link to the URI spec:

Thanks, Christopher.
# Posted By Charlie Arehart | 1/3/07 2:02 PM
This might be a little late in the conversation, but I have used this technique in CFML and ASP going back the last 4-5 years with no issues at all. I have always just not included the attribute at all, but going forward I will include the attribute but I will just leave it blank.
# Posted By Rudi Shumpert | 1/4/07 7:52 AM
I always do it as "form action="" method=...."

My pages validate too.

It does the same thing, but you are using the required attribute.
# Posted By Kevin Sargent | 1/4/07 1:22 PM
Thanks Rudi and Kevin for your confirmation of success using an empty ACTION. I'm really glad to see that, and thanks to everyone involved in the discussion. I'll revise the entry to remove the reference to leaving it off, but fortunately 99% of the entry will remain valid and useful to folks. :-)
# Posted By Charlie Arehart | 1/4/07 3:09 PM
Just a note:

Recently in a rushed coding frenzy I did:

action="?mcp=1234-4567-7890&id=whatever" method="post"

instead of putting them as hidden form fields.

It does work in most browsers, the form submits to itself, and you can read the url vars and form vars. It does NOT work in safari, and probably should NEVER be done anyways. Just something I learned, and do not do in production!
# Posted By Kevin Sargent | 1/9/07 1:43 PM
Kevin, I don't see anything in either the HTTP or URI spec that suggests that a query string (the part after ?) is not permitted in the URI value for a FORM ACTION. What's making you want to assert "do not do it in production"?

If it's just the failure in Safari, might that rather be an error in Safari?

And I guess I'd also ask if it's specific to the self-referencing form of ACTION being discussed here. I mean, even if you provided a filename, are you saying that you should not use a query string on an action?

I'm not saying you should. Just looking for clarification, for future readers, especially if someone can point to a definitive document on the topic.
# Posted By Charlie Arehart | 1/9/07 3:29 PM
My problem was with using a querystring only, no filename.

Using a filename would have been a standard relative path.

I didn't get a chance to check all browsers, I develop in FF, check in IE. A few people I work with have Macs, and noticed this problem.

"Do not do it in production" - simply because you can make it work in all browsers without breaking standards by adding the filename. Not to say query string only is not standard (I don't know either way) (might be only a safari bug?) But if you know it breaks a browser, and you can make it work while upholding standards, that's probably the way to think about doing it.

To clarify, as soon as I specified filename or used a absolute path, it worked fine in safari too.
# Posted By Kevin Sargent | 1/9/07 8:36 PM
to further clarify: action="" also was fine in safari

action="?id=3&this=that" broke in safari with the action url being formated like
# Posted By Kevin Sargent | 1/9/07 8:38 PM
Kevin, I don't mean to keep pouring water on your resistance to this approach. I mean, to each his own, but did you read that URI standard document that Christopher offered? Offering no filename for the action *should* cause the browser to create a "a standard relative path". You assert that using no value for filename in the action helps you avoid "breaking standards", but the points above clarify that specifying no value is within the standards.

Now you raise a good point. If the use of just a querystring fails on Safari, then it's certainly worth thinking twice before using it. It's still unclear if doing so is against the standard. Just because it fails on Safari doesn't make it "non standard" (nor is it clear that doing it makes your code "uphold standards".

I'm being a bit pedantic. I do appreciate your pointing out the challenge and solution, and thank you for bringing it up. Each can decide for themselves how to respond to all this.
# Posted By Charlie Arehart | 1/9/07 10:51 PM
thanks for responding.

I am in agreement with your post! I just thought I would point out that a querystring only may cause problems in safari, and to avoid that problem is simple, and doesn't break standards (not a hack just for safari.)

All Good!
# Posted By Kevin Sargent | 1/10/07 1:37 AM
This is an easy solution, but not one to depend on. A non-conforming user agent may refuse to submit the form entirely.

I'm currently working on a form where I've tried to get away with the empty action attribute. I tested it on my cell phone, but it refuses to submit the form; instead, it throws an "Invalid web address" error.

I recommend a full-blown URI for the action attribute.

(My cell phone UA string: Nokia6030b/2.0 (m3.35) Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Link/
Did you actually test this? On multiple web servers? using html?

On Apache/1.3.37 this results in a 405 error
The requested method POST is not allowed
# Posted By Experienced | 11/14/07 11:44 PM
@Experienced, can you kindly clarify who you're asking your question of? Was it me? or someone making a comment?

And if me, then what part of my original post are you referring to? My original suggestion that you need not include any Action? Or my update about leaving it empty?

To answer your questions, yes of course I "actually tested it", but no, I'll admit not against multiple web servers (sorry, just didn't think of that), but yes of course I was using HTML. What else might you think I was using? Seems an odd (almost surly) question.

Also, as the commenter previous to you had said, this could also be affected by browsers, so I'll ask you, what browser were you using? If we're going to get to the bottom of any aspect of this which doesn't apply to all, let's do it across the board.

I have to say I don't care much for your tone. Do you know me? (Or even if you're responding to a commenter, do you know that person?) You just sound awfully accusatory, like you're trying to prove a point, or assert that I've wasted your time (or that of others). Chill out. I was sharing a tip, and one that's helped me out (and others) quite a bit over the years. If it's not a perfect tip, that's indeed what the comments are for. But I'm here trying to help people. I'd like to ask you to do the same.

@Experienced, can you not interpret what it is saying? It is in plain English - it says that the POST method is not allowed - that doesn't mean that it happened because of you leaving your action attribute empty - Apache/1.3.37 obviously is not set up to allow post requests to your specific page, or that it is set up to reject post requests to that specific page, this has nothing to do with the action attribute! To work around the problem, you should google to try and find out how you can allow post requests to your specific page, or maybe use GET, or whatever
# Posted By will | 4/24/08 8:20 PM
I think that there is no violation of anything if I say action="". The spec says action attribute IS required - it does not require a specific content (it couldn't for it would be a dictate not standard).

I would fire any programmer who did not test for a variety of values of an argument including null, nothing, nada ...
# Posted By Lanny | 6/20/08 2:26 AM
Lanny, did you read the whole blog, especially the first box at the top (which I added in Jan 07), as well as the comments? Others pointed out, and I clarified that yes, the spec is that you should provide the Action. And as I'd said from the beginning, it works as discussed here whether it's there and empty or just not there.

Thanks for trying to help, though.
Charlie, you are correct.
# Posted By Lanny | 7/6/08 6:05 PM
FWIW, I found that with at least one browser (BlackBerry8700/4.2.1) action='' caused the form to not accept a submit. Seems like a bug on their side, but I can't find it documented.
@Frederick, that is a bummer about that phone. As you say, it seems to be a problem in the phone, but it does suggest that people be cautious about using the technique if they may have to support such non-standard browsers.
@everone (I know it's been a whiiile since this post was made but if I found it someone else might too)

Simple solution really... Take the following code (as an example)

<!doctype html>
<title>can the action attribute be empty - Google Search</title>
Hi - I am some body text.
<form action='' method='post'>
<input type='text' name='field'/>

now copy and paste it to this page: http://validator.w3....

Click the 'Validate' button.

Voila - the W3C validates the HTML code.

The code above uses the HTML5 spec which is what Google is currently using. I know they're using HTML5 because I copied the <!doctype html> tag from their HTML source.
# Posted By Michael White | 3/11/09 11:43 AM
So to be clear, Michael seems to be concurring with what I've said from the outset (about the value of an empty action), and he seems to be offering his clarification to address the commenters who've wondered if having an empty action is valid. Glad to hear that it is per the w3c validator (both the default html 5 it checks and also the "html 4.01 strict" and "xhtml 1.0 strict" option.)

Thanks for offering that, Michael.

For any who would wonder, I checked out leaving the action off entirely. While that does pass the default html 5 validation (and even "xhtml 1.0 strict"), it does fail both the "html 4.01 strict" and "html 4.01 transitional" validations. So again, you use that with caution.
NEVER use action="". It is an error, to which browsers respond differently. FF and IE may respond to this error by accident correctly (getting the same form), but Safari does NOT!. Safari responds to this error going to the base-href page, first page of website.
Best way to trigger a self action is using PHP, and then:
<form action="<?php echo $_SERVER['PHP_SELF'];?>">

or take the 'trouble' to fill in the url of the page...
Oh Harry, you're so virile and strong. Men must just shake in their boots with how strident and confident you are!

But it seems you're wrong, pal. I just tested this in Safari (4.02 on Windows), and it worked just as expected (posting back to the same page that had teh form, with no action).

So, if you're going to go bullying around people's blogs trying to tell them that they're wrong, please, come a little better prepared.

Or how about a little humility instead? Are you saying you have some example where it does what you say? Maybe it's the version you're running, or the platform.
I notice that Harry's comment referred to a couple more things, and I didn't address those. For instance, he referred to this being an issue with using action="". That tested fine in Safari, also, posting back to the page with the form, not "first page of website" as he contended. Further, since he mentions using a base href tag, I added that, and it STILL did not change the behavior. So I still stand by my assertions here.
Charlie, I am not so virile and strong as you think, but I am a serious webbuilder with serious intentions, okay? So keep out the crap and let's come to the facts.

I also made a simple form setup with action="" and indeed in all browsers including Safari, this seems to confirm your statement.

However, in a CMS I designed, a have a module in which by a program error (an incorrect PHP_SELF action call) an empty action was generated. I never noticed this, until a user tried this module in Safari, which I never did. The empty form action brought him to the root of the website.

This made me jump to the conclusion of my former message, that "Safari responds to this error going to the base-href page, first page of website.". But in the simple setup I made (your reaction challenged me to go into the deep :-) did not do that.
Thinking it over, I realised that in this module, which keeps track of menu items, I placed a base href statement, to ensure the menu in the module points at the website root.
Subsequently I added in the head section of my simple test setup a base-href statement, let's say:
<base href="http://www.carehart...." />
and see what happens in Safari, action="" does point to the base-href. You can check it for yourself:
and you can simulate this adding a base href to your own test-setup.

My conclusion is, that you are right, except in all Mac OS versions of Safari, when a base href is in the html code.
I can NOT speak for the Windows version of Safari, as I could not test that. You can do that, and I am curious about the results.

This blog by the way:
seems to confirm my experiences.

>So, if you're going to go bullying around people's blogs trying to tell them that >they're wrong, please, come a little better prepared.

Prepared enough?

Keep up the good work of web investigation. So do I...

Well, Harry, I still don't find confirmation of what you say. I visited the page you offered, on a Mac, and still the page submission remains on the page that showed the form. What are you seeing? Are we maybe having some misunderstanding about what you think should be happening?

Further, you have the base href pointing at the same location as the template itself. Even if what you saw could be somehow different, since the base url points to the same directory, we wouldn't see anything different.

But I've gone ahead and placed a copy of your code on my server, leaving the base href pointing at your server (for whatever that would be worth). Check it out yourself: http://www.carehart....

Again, the form submission stays on the same page. That's what I'd expect. It's what the SPEC says should happen (which is why I wonder that you press the point still). In fact, it's indeed what the other blog entry you point to says.

This is what really makes me think there's some misunderstanding. The other blog you point to says the same thing I do: you can leave the action empty, and according to the spec it will post back to itself, whether there's a base href there or not (and whether it points elsewhere or not).

So as for how I responded to your first comment, well, you did come across awfully strident and cock-sure of yourself there, which I didn't much appreciate. I've been blogging for many years, and it's rare that someone I've never interacted with comes onto my blog guns ablazin' and spouting "NEVER" do something I pointed out, and asserting further that I'm promoting laziness ("take the 'trouble' to fill in the URL of a page").

The blog entry explains why one may otherwise go through hoops to "fill in that URL" on a dynamic page. So does the other you pointed to.

Sure, if there's some situation where perhaps some modern browser on a modern OS fails to honor that, it would be worth noting. Even then, I'd expect it to be noted in a more civil manner. Like you say about yourself, I have only sincere "intentions" to share information and a desire for "investigation". Just here trying to help others.
Hello Charlie,

Just one or to sentences about way of putting things, sorry if my first reaction was too arrogant, at least the interpretation of it, that was not my intention. Shall we put that aside?

I just visited my own example on your website
I will document exactly what happens, using the above link.
In Firefox I see 'nothing' happening, meaning, the form page just quickly refreshes and stays the same on 'Submit'. Just as you state that should happen.
In Safari 1.3.2 (v312.6), on Mac OS 10.3.9 click on 'Submit' makes the form page dissappear, and the page shows the url defined in the base href tag, in this case my own website.
In Safari 2.0.4 (419.3) on Mac OS 10.4.10, exactly the same happens.
That client of mine, experienced the same in the newest Safari on Mac OS 10.5 within my cms.
In the blog I mentioned in my previous message, a similar behaviour with Safari is described in one of the comments of the blog, that is comment nr. 19. For the record, that was
Interesting though is Frank Weindel's statement there: "We have a form which uses a blank action attribute and on the versions of Firefox, IE, and Safari I've tested, it points correctly to the current page." So he reports correct Safari behaviour from his own testing. Later on he mentions users reporting the same Safari experiences as I have. In comment 20 he says this was on Safari version 3.2.1. on Mac, and Safari 3.2.2. on Windows.
You also state that you do not experience what I experience in Safari.

>This is what really makes me think there's some misunderstanding.
No, it's really happening. For the record, only in (some, not all?) Safari versions, and only when the condition is met that a <base href="whatever"> is in the head section. But perhaps there are other conditions to be met? I cannot imagine that a Dutch Mac OS and Dutch Safari acts different from an English OS/Safari.

So this is a peculiar riddle in which there still is a question, on which Mac OS and which Safari version do you encounter the correct behaviour?


OK, my testing was on OS X 10.4, and Safari 4.0.2. Before someone jumps on Harry wondering why he'd be worried about such a seeming "old" version, I see from wikipedia that 1.3.2 is in fact the latest Safari version supported on OS X 10.3 and 10.2 (http://en.wikipedia....(web_browser)#Version_compatibility).

OK, so we now seem to have a specific concern for people to be aware of: those using that version of Safari will have a problem with a page using this approach if the page adds a base href. Glad we got to the bottom of things.

So, should one "never" use the approach? I'll still say that's a little harsh. Should Apple fix this, since it violates the spec (it would seem). But maybe it's a subtlety in the spec (about the base href) where they're right and everyone else is wrong. Since it doesn't do it in 4.0.2, they either fixed it to line up with the spec or to maintain better compatibility with other browsers that don't have that issue.

I suppose if one wants to avoid a problem for those users on Safari 1.3.2, and they may use the base href tag, then forewarned is forearmed. Thanks for the clarifications, Harry.
You're welcome Charlie.
One thing puzzles me, why some versions of Safari in MacOS DO the action="" thing with the <base href>, and others don't...
But I decided to stop thinking about it.. I agree to your final conclusion, be aware, or beware in this matter.
Web service developers like us using html inside jsp pages never use the 'action' attribute, because there would be in almost all cases multiple actions on the form content. For example the same form might be used for a add functionality where all the data in the form is inserted or update functionality where only certain data may be updated. If action includes submitting any of the multiple submit buttons below the form, it is not possible to identify a single action URI
# Posted By M A J Jeyaseelan | 8/13/09 11:14 PM

You said that you never use the 'action' attribute. As Charlie established early on, that's invalid, unless you mean you always use an empty value for the action attribute.

As far as the same form doing different things depending on how it's submitted, you can do that easily and validly with multiple submit buttons, using the value attribute for the input type="submit" element to distinguish purposes.
Who still uses a base-href?

Oh, reverse compatibility... like to the old sites that are not using action="".

In a javascript and DOM world... on virtual servers with heavy htaccess rewrites... who can safely use a base-href?

The purpose of upgrading browsers, is to fix non-functionality and security holes. Allowing extended functionality to unsecure browsers with many well known exploits is doing more harm to your customers. If that 0.0000001% of the running population is worth the additional effort, and possible non-functionality of the alternative codes, which often still fail more than 0.0000001% on compatible browsers, then power-to-you!

Mac is dead, and is now an IBM inside. It won't be long until they finally drop the whole OS too. It offers no advantage over IBM's now, because it is an IBM now. Once, they were faster than IBM's at "Certain things"... Now, they can't even keep up with the speed of the IBM's they are run on. (The non-mack versions of the same software run faster and more reliably on an equivalent valued IBM PC.)

This function, even with those two rare instances, is one of the best forgotten and unknown treasures that original HTML had to offer. Still as functional as BR and HR and P and B and I and U and IMG and FORM itself.

Great publication, and great corrective editing! (That impressed me more than the actual command.)

However, you should reverse your comments order. No-one wants to read a bunch of old, expired, out-dated, comments first. Makes it look like the article is still old, and may be out-dated. (Unless you flip to the last page of comments.)
# Posted By JasonD | 9/25/09 7:19 AM
JasonD, I believe your comment was "old, expired, out-dated" before you even wrote it. I'm pretty sure neither my Dell nor my co-worker's Apple has anything made by IBM in it at all. Your speed claims are simply false, and you clearly aren't aware of the advantages of semantic coding to compare action="" to the benefits of <b>, <i>, and <u> (as I'm quite sure you're not referring to them in their revised HTML5 senses).

Charlie, great entry and discussion stream!
One more note: I am aware that the "IBM PC" used to be the generic term opposed to Apple systems; however your use of now-antiquated terminology reveals your true lack of knowledge. (The first computer I used was a PC XT.)
# Posted By Scott Buchanan | 9/30/09 11:35 AM
Just a thought: Wouldn't setting <form action="#"> solve the problem? This is a valid URI in terms of the W3C and since forms unlike fragment-links will always be sent back to the server. The browsers - according to specs - must use the current page URL for the fragment reference.
# Posted By icarter | 1/31/10 2:32 AM
@icarter, that's a good point, for those browsers where an empty value for ACTION may not work (see discussion of Safar1 1.3.2 in the comments above, where it failed). But for most, just using an empty value will suffice.

Either way (whether empty or just #) does seem an improvement over trying to dynamically generate the current page name, which was the real point of this (now 3-year old) entry about self-posting forms.

And for anyone who thinks twitter has totally erased the need/value of blogs, this is a statement against that. :-)
I use this all the time. and there is 2 reasons why i do.

1. It works. it has never failed and it makes perfect sense in relation of absolute url notation.

2. it keeps urls tidy.. i try hard to have tidy urls with out using mod rewrite and using a blank action means by form can most with out adding the file.ext to the url

excellent :)
This is a great example of an issue that most programmers/developers don't understand. It's not a technical question, it's about business. Do you really think Microsoft, who's spent ungodly amounts money on IE, and Mozilla, whose bread and butter product is firefox, are going to allow their new browsers to break on forms? No. They're not giving up their market share of browsers over that. What does the average user do if their browser continually doesn't work- they switch browsers.

I don't blame anyone who chooses not to use this, because I agree you would be up a creek if it stopped working.

But I certainly wouldn't snoot your nose down at anyone who chooses to use it - ridiculous
# Posted By Karl | 12/16/10 12:22 PM
Karl, can you add a little clarification of who you were speaking to (with regard to "snooting your nose down" at someone)? I don't think I did that in my entry, so perhaps it's a particular commenter you're referring to? Since that blog entry is from nearly 4 years ago, and some may see the comment popping up quite out of the blue (either by email if on the comment subscription list) or in the "recent comments" pod on my blog, a little more clarification would be appreciated. Thanks.
Had hope the action = "" would work.
Try the # and the self server php action. If only $i has the submitted value to make some decision making in my php program. I am a newbie. tx
<form action="" method="post">
<p>Your Name: <input type="text" name="yourname" /><br />
E-mail: <input type="text" name="email" /></p>

<p>Do you like this website?
<input type="radio" name="likeit" value="Yes" checked="checked" /> Yes
<input type="radio" name="likeit" value="No" /> No
<input type="radio" name="likeit" value="Not sure" /> Not sure</p>

<p><input type="submit" value="Send it!"></p>

<?php $i = $_POST['yourname']; echo $i; ?><br />
<?php echo $_POST['email']; ?><br />

(End of Code)
# Posted By Anita | 4/2/11 9:50 PM
Anita, I can't tell if you're asking a question."Try the..."? "If only..."?

Also, I don't do PHP, so I don't know the answer if you are asking for help. Mine is a ColdFusion blog (and that's the example code I'm showing above), but of course the concepts would apply regardless of server.

Are you saying you get an error on your last lines of code? I wonder if it's because when the page first is shown, the form has not been submitted. Again, I don't know PHP. Since you say you're a newbie, I'll note that this is a common kind of mistake in any web app language.

It would seem a simple solution (to confirm whether your error has anything to do with the issue I've raised, of leaving there to be no action) would be to go ahead and fill in a full url/filename for the action attribute. If it still fails then, then again it may be your attempt to access the form data before the form has been posted. I would need to ask you to take your question elsewhere, though, as I just don't have an answer for you (and don't know if other readers will chime in).
Tx Charlie for your reply.

Spend a day on null action and thus excuse my posting. Had hope to edit to make it clear. A day to look at other sites, to find simalar posting and knowledge on null action.

I try action = "#" and action self server but no luck.

I could have use a script for the form submission. And an action script to manage the $post[ attribute ] for the submitted values. Two scripts and post value would be passed properly and thus manage on server.

But since null action implies no action and thus the enclose simple code is a form submission. Also included is the assignment of the form values. The value is pass to $i and is display by echo. Again, this was a test routine comprising of html form submission followed by some php code to display submitted name and email. I did not use java after the form submission for I wanted server side mananagement.

No, I am not asking a question for I let the code speak for itself. And I spend a day for I had hope values would be maintained. This is one block of code that is submitted and executed. THus form is display, user enter information, and the entered information is displayed. Error is relative on if the variable address is maintained to use submitted with null action.

Newbie is a humble form of not knowing the null action attribute and thus seeking reference material. I am not asking for answer but passing information to any other programmer on what happen to me. In my case, php. Just upset I wasted a day on null action. tx
# Posted By Anita | 4/4/11 1:48 PM
Dear sir/Madam,

I am not good in XML, please tell me what is the purpose of the post -action tag in xml (please see below tag).
<entity-field value="value"> Risk_Profile</entity-field>
# Posted By Oai Nguyen | 5/31/11 8:07 PM
@Oai, I suppose that you did a google search for that phrase (post-action) and it led you here, but I'm afraid it has absolutely nothing to do with the point of this blog entry. More to your point, I don't know anything about it and so can't offer anything more. You really will want to take your question elsewhere (perhaps stackoverflow.com).
I think the behavior has been disabled with the hotfix described here: http://www.adobe.com... I have a few forms to fix!
# Posted By Steve Hammonds | 12/15/11 4:10 PM
"Again, I'll offer another post that shows a unique way to take advantage of this in doing login authentication."

Well, I've gone bats looking for this post, because it sounds like exactly what I need to read. Where is it?
# Posted By Henry | 2/12/12 10:43 PM
Sorry, Henry. Life got in the way and I never did get around to that post.

But are you saying you found this entry while looking for that solution? If so, now that you've read this entry on self-posting forms, do you see how this approach could work to solve that problem better than the traditional redirect approach?

The point is that you don't need to have your authentication code redirect someone to a new login page, when you detect their session has expired. If you do that, as you may realize, you then have to go through the hassle of carrying along the original URL requested including any querystring, so that you can get them back to the originally requested page after logging in. That can be a bit of a hassle, especially if it can be avoided.

If you use this self-posting form approach instead, first the URL need not change. Your application.cfm/cfc can detect that the user's session has expired (your login variable ow whatever has disappeared), and it can present a login form right then and there, "on the page they requested" (so they don't see a new URL). That form then can post back to itself (the "same page" they originally requested, with the querystring will remain as well).

I've just poked around to see if anyone else has blogged about doing it, but I don't find any. I'll try to get a new blog entry out with actual code to show this.

Until then, Henry, since you're motivated to find the solution, let us know if you try it yourself and have any experience, pro or con.
I'm not a profesional web coder, so a lot of the implications of this are lost on me.

The presupplied user login web page for the User Manager function in the Mikrotik router contains precisely this type of self-posting form. It is written only in plain HTML with CSS and a smattering of Javascript that validates a few fields, but otherwise nothing executable that would respond to a self-posting form. I searched for this topic to find out what I should expect from those semantics. In this real case, I don't believe the form ever does come back to the same page, but gets shunted to one of two others by what I suspect is some special-case black-box magic in the router's internal web server.

Your comment that self-posting forms were uniquely suited to login applications led me to hope that by understanding this relationship, I might be able to divine why the coders used this syntax and what they might be trying to do behind the scenes. If there's nothing more mysterious than the preservation of the original fetch reference, it doesn't really illuminate the black box as I hoped it might.
# Posted By Henry | 2/18/12 4:21 PM
Ah, ok, Henry. To be clear, my site here is nearly entirely in support of the web application server called ColdFusion, so in my reply to you (and indeed for part of the entry) I was describing things in that context.

I have no idea of anything about the internal operations of your Mikrotik router, but I will say that it may use a similar approach to what I was alluding to about ColdFusion: it may have something that always runs before whatever page is requested--so that if a page requests itself, then there is server-side processing that you never see or know about but which will take your form post info and do something with it, before it shows you whatever page result is displayed.

So, sadly, no, there's nothing more that this entry or I can tell you about what's happening in your page request, but I hope now that at least you see how technically it can be that this page, that "posts to itself" that you see, may actually be doing more (on the server, in your case, within the router) that will indeed be hidden from you. I'm afraid, then it is still going to be a black box for you.

But to be clear, my entry is written instead for those who develop web application software, and who do control their web server and what it does.
Hi people Google brought me here.
I was unsubscribing from an unknown email list and thought it looked suspicious. When I looked at the HTML the form had a method but no action.

Do you guys think it's a dummy/fake unsubscribe page?

<form name='unsubform' method='POST'>

Please accept our apologies if you received any unwanted mail. We absolutely<BR>
remove all addresses of those who do not wish to receive mail from us.<BR>
We already have your email address, so the only purpose of this page is to<BR>
remove you from all future mailings.<BR>
<b><font name='times' size='4'>Please confirm your UNSUBSCRIBE request:</font></b><BR>
Email Address: <input type='text' name='email' class='spro' size='30' maxlength='255' value=''><BR>

<input type='submit' name='Submit' value=' Unsubscribe '><BR>
<input type='hidden' name='client' value='TBek'>
<input type='hidden' name='listname' value=''>
<input type='hidden' name='msgid' value='9021200210'>
<input type='hidden' name='formactive' value='Y'>
<input type='hidden' name='html' value='6'>
<input type='hidden' name='text' value='3'>

The whole page is here
# Posted By Rod | 2/20/12 2:38 PM
regarding this post:

# Posted By Michael White | 3/11/09 11:43 AM


Simple solution really... Take the following code (as an example)

<!doctype html>
<title>can the action attribute be empty - Google Search</title>
Hi - I am some body text.
<form action='' method='post'>
<input type='text' name='field'/>

now copy and paste it to this page:

Click the 'Validate' button.
Voila - the W3C validates the HTML code.


I just tried the above and got this error:

Bad value for attribute action on element form: Must be non-empty.
# Posted By sean | 3/16/12 2:38 PM
Sean, I would suspect that this is because the validator tool now defaults to checking against the html5 specification (see the DocType select control on the page). When Michael posted that in 2009, I'm sure the default was something about HTML 4.

Indeed, If you change that select control (on the validator page) to "html 4.01 transitional", this action being empty is not flagged as an error.

But what was your real motivation in pointing this out? Are you interested in the idea of a self-posting form, which is the real subject of the entry?
hiya charlie!

very cool of you to respond so quickly.

thanks for pointing out that you can toggle select control. i just tested this and, yup, you are right!

and per my motivation, i was indeed interested in the mechanics of a self-posting form! i'm putting a simple email form together now, and there seem to be sooo many examples of forms referencing an action which is saved a separate file, but i was curious if it had to be that way. after googling this issue, i got to your post, read all the comments, and then just got real curious!

anyways, most excellent of you to both bring this issue up, and keep the discussion alive and well.

# Posted By sean | 3/16/12 6:48 PM
Glad to help, Sean. Thanks for the follow-up, and the kind regards.
RE: "I'll offer another post that shows a unique way to take advantage of this in doing login authentication."

I can't find that post. Where is it?
# Posted By Bilbo Baggins | 10/21/12 10:39 AM
Just never got to it (back in 2007). Sorry.

I did respond to someone else who asked, earlier this year. See the comment above, here:

I'll modify the entry to strike out that sentence and point to the comment. Just don't know if/when i may get to doing a new entry on that. Too many more urgent priorities right now.
I have been using this technique for quite some time. Worked like a charm until the recent CF hotifxes. I am running CF9. Any suggestions? I am having to go back and change cfforms to include action with script name and url params.
# Posted By Anita Austin | 5/30/13 7:24 PM
I've been using this for a long time as well without issues. At one time a coworker could not get this to work in his local dev environment, but we were never able to figure out why.

We recently moved from CF9/Jrun to CF10/Tomcat, both with IIS 7.5. This functionality broke on both our production and my local development environment. So, the issue does not seem to be at the browser(client) level, but on the server side. For my own sanity, would love to understand why this no longer works.
# Posted By John Sieber | 11/6/14 2:03 PM
@John, sorry I missed your comment here last week. So I'm curious your challenge (with respect to using an empty or no ACTION attribute on a an HTML form). You say you see CF processing things differently depending on the version of CF.

But I can't see differences in CF versions having any impact at all on how CF processes a request from page with a plain FORM tag. That's what my blog entry here is about.

But maybe you mean you're using CFFORM, and that's very different. In that case, CF *writes* your HTML form tag for you, and there can be differences in how it works in different versions--and perhaps based on what you have specified in the CFFORM tag and its attributes and values.

Now, since you say things changed on a move to CF10, I'll note that when it first came out, there was a beta (and docs) where they DID plan to change how CFFORM worked if there was no ACTION attribute. But as you can see in this comment by Aaron Neff to a blog entry I did then (http://www.carehart....), he commented that that had been changed in the final release.

But maybe since then, one of the 14 updates to CF10 has changed things.

Along the same lines, what update do you have applied to CF10?

Most important: have you rebuilt the web server connector (all that you may have) after applying updates to CF10? That could well be an explanation to why things may not be working for you, even if perhaps a subsequent update "should have" left things working for you. For more on that, see my blog entry: http://www.carehart....

I really think one of these things may have your answer (and could be why you may find different people also on CF10 may be experiencing things differently than you.)

Do let us know what you think and whether this helps.
Hi Charlie,
Thanks for the reply! You are correct that this ended up being an issue where cfform was being used. In my testing, cfform was writing the blank action as /index.cfm, essentially redirecting the form action back to the root of the site.

This behavior started when we upgraded from CF9 to CF10. We went directly to Update 14 and did rerun the the connector configuration tool under administrative privileges to rebuild the connector.

Ultimately, I ended up updating the action attribute for the forms that were affected. This is extra motivation to move away from cfform and use vanilla form tags instead.

Thanks again for responding and offering advice.
# Posted By John Sieber | 11/12/14 2:18 PM
@John, glad to help and thanks for the update. But it is lamentable then that it seems this "feature" which was at first there, then not there, is now "back". And all the worse when I could find absolutely no reference to it other than Aaron's comment in that blog entry: -(

Oh well. Glad you got things sorted out.
The W3 spec specifies that the action is required, but it does not specify that it cannot be an empty string. I test my forms initially in this way when I want to concentrate on certain issues. At run-time, if one wishes to avoid the pitfalls of the 'SELF' method, one can still specify the same URL as the current form URL in the action to make the code more readable and also to anticipate future requirements with user agents (in case they don't consider an empty string as valid).
# Posted By Ghada | 11/4/15 11:39 AM
OK, I'm going to shut down comments on this post (something I rarely do), as it's going rather far afield of the original intent (in 2007).

Ghada's comment is correct. People can indeed (and in some cases perhaps should) put a value in the action.

But I was never arguing that they shouldn't. (And I don't know that Ghada is necessarily contending with me on this, but again my point is that it, like many comments, is going beyond the purpose of the original post.)

More than that, I just don't think there's more that needs to be said on the matter, or more to the point, that anyone who reads the whole post and all the comments will really have anything new to say.

This was a post from 2007 about how CF developers then used to (and perhaps still do) jump through hoops to create a self-referencing form. I offered a solution to consider, and some ahve offered counterpoints.

I'd say let's let this stand, as is. :-)
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting