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
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:
...
or more involved:
<cfif CGI.QUERY_STRING NEQ "">
<cfset action=action & "?" & xmlformat(CGI.QUERY_STRING)>
</cfif>
<form action="<cfoutput>#action#</cfoutput>" method="post">
...
All this could be replaced very simply with:
...
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
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:
<input type="Submit">
</form>
<cfif cgi.request_method is "post">
Posted to itself
</cfif>
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?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- 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
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.
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.
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.
According to the HTML 4 spec Section 17.3 the Acction is a required attribute of the form element:
http://www.w3.org/TR...
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.
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.
<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..
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.)
http://www.ietf.org/...
My pages validate too.
It does the same thing, but you are using the required attribute.
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!
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.
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.
action="?id=3&this=that" broke in safari with the action url being formated like
domain.com/filename.cfm?id=3&this=that?id=3&this=that
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.
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!
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/6.3.0.0.0)
On Apache/1.3.37 this results in a 405 error
The requested method POST is not allowed
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
I would fire any programmer who did not test for a variety of values of an argument including null, nothing, nada ...
Thanks for trying to help, though.
Simple solution really... Take the following code (as an example)
<!doctype html>
<head>
<title>can the action attribute be empty - Google Search</title>
</head>
<body>
Hi - I am some body text.
<form action='' method='post'>
<input type='text' name='field'/>
</form>
</body>
</html>
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.
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.
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...
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 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:
http://www.marsandmc...
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:
http://www.thefuture...
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...
Harry
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.
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
http://www.carehart....
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
http://www.thefuture...
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?
Harry
So,
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.
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.
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.
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.)
Charlie, great entry and discussion stream!
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. :-)
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 :)
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
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
(Code)
<html>
<body>
<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>
</form>
<?php $i = $_POST['yourname']; echo $i; ?><br />
<?php echo $_POST['email']; ?><br />
</body>
</html>
(End of Code)
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).
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
I am not good in XML, please tell me what is the purpose of the post -action tag in xml (please see below tag).
<post-action>
<entity-field value="value"> Risk_Profile</entity-field>
</post-action>
Well, I've gone bats looking for this post, because it sounds like exactly what I need to read. Where is it?
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.
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.
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.
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'>
<BR>
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>
<BR>
<BR>
<BR>
<b><font name='times' size='4'>Please confirm your UNSUBSCRIBE request:</font></b><BR>
<BR>
Email Address: <input type='text' name='email' class='spro' size='30' maxlength='255' value=''><BR>
<BR>
<input type='submit' name='Submit' value=' Unsubscribe '><BR>
<BR>
<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'>
</form>
The whole page is here
http://ehroge.com/un...
# Posted By Michael White | 3/11/09 11:43 AM
************************************************
Simple solution really... Take the following code (as an example)
<!doctype html>
<head>
<title>can the action attribute be empty - Google Search</title>
</head>
<body>
Hi - I am some body text.
<form action='' method='post'>
<input type='text' name='field'/>
</form>
</body>
</html>
now copy and paste it to this page:
http://validator.w3....
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.
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?
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.
cheers!
I can't find that post. Where is it?
I did respond to someone else who asked, earlier this year. See the comment above, here:
http://www.carehart....
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.
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.
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.
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.
Oh well. Glad you got things sorted out.
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. :-)