The Daily WTF: Curious Perversions in Information Technology

gwenhwyfaer · 2006-03-28 Reply Admin

bullseye:
<a href="#" onclick="myform.submit();return false;"> ...</a>

PLEASE don't do this! The number of times I've clicked on what should have been a button on some page http://some.url/page and found myself directed to http://some.url/page/# because onClick events were silently discarded... If it needs to submit a form, make it a submit button. If it needs to execute JavaScript locally, make it an ordinary button. If it's a link, it should take me somewhere AND NOTHING ELSE.

Cooper · 2006-03-28 Reply Admin

oh dear - that didn't work all that well....

nobody · 2006-03-28 Reply Admin

And here I thought that Google's motto was "Don't be Evil!"

public class PaulaWebCrawler { public void onGet(Page page) throws Throwable{ page.delete(); throw new FileNotFoundException("Brillant!"); } }

paddy · 2006-03-28 Reply Admin

Anonymous:
Uh ... anybody ever hear of 'GET' actions always being benign and 'POST' actions changing things?
Even if you're gonna use a login cookie, wouldn't you make the user *not* be logged in unless the cookie was present?
Do web developers not realize that you can telnet to port 80 and type anything you like?

Thats why you have to authenticate the user on each request. Once they enter the username and password (via POST of course), you need to set a cookie that contains a fresh unpredictable value that is unique to that user's autheticated session, and then check that value with each request.

kipthegreat · 2006-03-28 Reply Admin

Anonymous:
I seem to recall a similar issue with another Google product - it was one of those things that's supposed to speed up internet browsing by simulating the user clicking on everything. If this is the case, even with a good authentication scheme, you're in danger of deleting everything, because this is a direct user simulation (allowing access to all user cookies and such).

Google Web Accelerator. As I said, that's because people were using GET requests to implement destructive actions, which is a big no-no. All GWA did was expect that the sites you used conformed to the HTTP 1.0 and 1.1 specs. To be frank, the people who produce sites and apps that would let something any spider, proxy, or prefetcher do that deserve a Darwin award for stupidity.

Or a Daily WTF.

It should be noted that neither Google Web Accelerator or Firefox will prefetch a URL containing query strings (although both mention in their FAQs that they retain the right to do so in the future in accordance with the HTTP specs):

http://webaccelerator.google.com/webmasterhelp.html#prefetch3
http://www.mozilla.org/projects/netlib/Link_Prefetching_FAQ.html#Are_there_any_restrictions_on_what_is

2006-03-28 Reply Admin

I can't understand why there's so many sites using javascript for simple navigation. Everything's bad about it:
- hovering a link reveals something as meaningful as "javascript: void();",
- you can't open a link in a new tab (didn't try IE7, but hey, can't be much better),
- you can't bookmark a link to view it later,
- when there's a href="#", it sends you back to the top of the page, which never is what you want to do.
And for what? Most of the time it's a "article.aspx" link with parameters. You still land on a page with a long url (like article.aspx?articleid=24252525&stuff=something ), it's just a Rube Goldberg machine dancing flamenco on the philosophy of the web.
There's worse things though. There's navigation in flash.

paddy · 2006-03-28 Reply Admin

gwenhwyfaer:
bullseye:
...

PLEASE don't do this! The number of times I've clicked on what should have been a button on some page http://some.url/page and found myself directed to http://some.url/page/# because onClick events were silently discarded... If it needs to submit a form, make it a submit button. If it needs to execute JavaScript locally, make it an ordinary button. If it's a link, it should take me somewhere AND NOTHING ELSE.

Then someone did the onClick wrong?

I think the old "hyperlinked documents" model is failing to keep up with the fact people are writing more and more complex systems, and by all means, use links forms, or whatever. Last time I checked, when you show an HTML layer over (for dynamic menus etc) form elements or any embedded element gets painted overtop of the HTML, even though it is on a layer behind it. Thats a pretty good reason to use links instead of fat widgets I'd say.
Also, GET requests are good for "modifier" requests at times, do you want a form button just to change a default language or some indescript setting? To update a hit counter?

I think its a problem when a programmer has a programming stylistic reason for limiting the freedom of the designers.
Give them some guidelines, and hard rules where they really are needed, but seriously if a designer can come up with a richer and more appealing interface that use links to submit form posts, there is no reason in the world they should be forced to dumb-down their design.

Whiskey Tango Foxtrot? Over. · 2006-03-28 Reply Admin

ammoQ:
Some years ago, a spider got caught in on of our websites which had a sophisticated tree view CGI script that used long strings of 0 and 1 to indicate which branch of the tree is opened (displays its subbranches) and which is closed. To make it worse, this parameter was implemented as a virtual path, so e.g. http://www.somedomain.at/cgi-bin/treeview/000000000 showed the tree with all branches closed and http://www.somedomain.at/cgi-bin/treeview/111111111 showed the tree with all branches open. Well, it all amounted to the equivalent of a DOS attack. That's when we learned what robots.txt is all about.

I look forward to the day I get a full explaination of your system. You should post it here.

[;)]

2006-03-28 Reply Admin

ammoQ:
Some years ago, a spider got caught in on of our websites which had a sophisticated tree view CGI script that used long strings of 0 and 1 to indicate which branch of the tree is opened (displays its subbranches) and which is closed. To make it worse, this parameter was implemented as a virtual path, so e.g. http://www.somedomain.at/cgi-bin/treeview/000000000 showed the tree with all branches closed and http://www.somedomain.at/cgi-bin/treeview/111111111 showed the tree with all branches open. Well, it all amounted to the equivalent of a DOS attack. That's when we learned what robots.txt is all about.

I had something happen like that once - it was a calendar that went backwards and forward over events. It would go pretty far into the past and future if you just kept on clicking on "Previous Month" and "Next Month". These were simple links, like "calendar.php?y=2006;m=3".

As it turns out, Googlebot is smart - eventually it'll give up after going through pages that are only linked by one page. I guess when PageRank hits 0, it doesn't bother caring what the page links to.

MSN's bot, on the other hand, was not. I noticed that my website suddenly had something like 3GB/month of transfer over what it normally had. Going through the logs, I found out that the #1 user-agent on my website was "msnbot". So it got thrown into "robots.txt" and was told to stay out of the calendar.

Eventually I just got rid of the calendar completely - I never bothered checking why, but I think the SQL query it used to build the calendar was a bit of a WTF itself since it managed to overflow MySQL's temp space after running for a while.

I love how there's no preview feature with this forum... here goes nothing, gotta hope this post doesn't get mangled like all my previous ones did...

ammoQ · 2006-03-28 Reply Admin

Whiskey Tango Foxtrot Over:

I look forward to the day I get a full explaination of your system. You should post it here.

[;)]

I've written that system back in 1997 or 1998 and it was one of my first non-hello-world CGI programs. Since it was written in C and CGI libs were sparse then, using virtual paths was slightly easier than parsing a HTTP Get. And beside that spider issue, it worked pretty well. Today, in the age of AJAX, Web 2.0 and what-not, it's obviously an easy laugh (and no longer used).

rob_squared · 2006-03-28 Reply Admin

your mom:
the forum software ate my colon

That is, quite possibly, the most disturbing thing I've ever read.

loneprogrammer · 2006-03-28 Reply Admin

paddy:

I think the old "hyperlinked documents" model is failing to keep up with the fact people are writing more and more complex systems, and by all means, use links forms, or whatever. Last time I checked, when you show an HTML layer over (for dynamic menus etc) form elements or any embedded element gets painted overtop of the HTML, even though it is on a layer behind it. Thats a pretty good reason to use links instead of fat widgets I'd say.

No, that's a bug in IE. Every other web browser does not do this. IE should be fixed to respect the HTML standard.

paddy:

Also, GET requests are good for "modifier" requests at times, do you want a form button just to change a default language or some indescript setting? To update a hit counter?

No, that violates the HTTP standard!
Quote RFC 2616:

13.9 Side Effects of GET and HEAD

   Unless the origin server explicitly prohibits the caching of their
   responses, the application of GET and HEAD methods to any resources
   SHOULD NOT have side effects that would lead to erroneous behavior if
   these responses are taken from a cache.

brazzy · 2006-03-28 Reply Admin

OK, guess it's time to reveal my dirty little secret: I did exactly the same thing once, on the first webapp I ever wrote, hacked together in PHP. It ran locally on my own box, as did the search engine I was toying around with...

kipthegreat · 2006-03-28 Reply Admin

gwenhwyfaer:
bullseye:
...

PLEASE don't do this! The number of times I've clicked on what should have been a button on some page http://some.url/page and found myself directed to http://some.url/page/# because onClick events were silently discarded... If it needs to submit a form, make it a submit button. If it needs to execute JavaScript locally, make it an ordinary button. If it's a link, it should take me somewhere AND NOTHING ELSE.

Come on, having a "view text only" button at the bottom of a page would look retarded. But having a "?textonly=1" link violates standard. But an onclick:submit() link works nicely for anyone not trapped in 1998.

2006-03-28 Reply Admin

Anonymous:
First, don't use query strings, use forms. That's what they're there for.

And it's possible to style buttons so that they look decent or the same as a link. I've done it many times myself.

But what about browsers without Javascript? I'm writing up a site that needs to work on IE and Mozilla as well as mobile phones and text-based browsers (using different pages, but the same basic page layout). How do I make a 'delete' link without the ability to script an OnClick event?

Does that mean that I'm going to have to make the mobile-phone version of the 'delete' page a droplist and submit button, rather than a simple 'yes' link? Ouch.

marvin_rabbit · 2006-03-28 Reply Admin

Anonymous:
Total agreement. And it's not just "destructive" actions, but *any* action which causes a stateful change to the data is supposed to be performed by POSTs. That's sorta the whole point of having two separate types of requests in the first place.

Not quite anything. For instance, every time your webserver writes to its log file, you're causing a state change. However, such changes are ok because they don't interfere with GET's idempotency: you can do it time after time, and it's the same as doing it once: the extra data doesn't interfere with the running of the app.

What these idiots were doing, now that is another matter entirely.

Personally, I'm surprised nobody's brought up the "but form buttons are so ugly" chestnut. I've a way to smack that one down too.

Ahem:
<chestnut>
"But form buttons are so ugly."
</chestnut>

(Just curious.)

Hubert Farnsworth · 2006-03-28 Reply Admin

kipthegreat:
Speaking of which, is anyone else annoyed that when a post in this forum gets 50 replies, the site uses POST rather than GET to go to replies 50-99? So whenever I'm on page 2 and hit refresh I get prompted as to whether I want to resubmit form data.

Yes.

Hubert Farnsworth · 2006-03-28 Reply Admin

your mom:
what about links such as this?

You know what? I've got noscript installed in Firefox. Usually, when I encounter submit links that do nothing, I even take the trouble of looking at the source code. Doesn't work because of javascript? There's an easy solution.

click on that little cross on the right top of the window
go to the competitor's website

That easy.

2006-03-28 Reply Admin

Anonymous:
Security though client-side reliance doesn't pay off. And they were just unfortunate really, and uhm, had a pretty bad design too ... nevertheless.

No, you don't understand - mangement is earning their big bucks. The problem, as stated, is the technical design of the authentication component; the solution is to "managing the problem" so that the problem can be crossed off the list. Problem sovled, no code change; better still, all future instances are the customer's fault! No more support cost - only more revenue possibility; and you want to change the code?

2006-03-28 Reply Admin

Far me it from me to point out how utterly retarded it is to (ab)use JS like that to make a link submit a form, whether using the javascript: pseudoprotocol, or on an onclick event. Seriously, people, use a proper friggin' form button! For the sake of a demo, here's a page on my wiki: http://talideon.com/wiki/?doc=WikiEtiquette. See the use edit version link at the bottom? That's no link, it's a form button, and it's a form button because clicking it changes the wiki's view state. See how it looks like the links to each side: CSS.

Seriously, if you're going to do something, do it right and don't abuse the browser's other facilities just because it might seem easier. Don't fight the browser, use it as it's intended to be used. If you don't, you'll just end up with an app that little more than a mountain of hacks.

2006-03-28 Reply Admin

Solve the security problem first, then convert your simple links to POST requests...

Or... do both. If you've got non-idempotent GETs in your app, it can still break even if you've done the authorisation (that's what you meant: authentication is only proving who you say you are, not that you're allowed to do something. That's authorisation.) side of things. That's the lesson of GWA.

2006-03-28 Reply Admin

Now they don't, but initially GWA did, and the only reason why they stopped is because it broke a bunch of apps that retardedly used GET in a destructive manner.

But that still doesn't excuse abusing GET like that. People should be beaten over the head with that factette.

2006-03-28 Reply Admin

nobody:
public class PaulaWebCrawler { public void onGet(Page page) throws Throwable{ page.delete(); throw new FileNotFoundException("Brillant!"); } }

Or, more traditionally...

public class PaulaWebCrawler {
  public Bool onGet(Page page) throws Throwable {
    Bool result;
    if ((result = page.delete()) == Bool.False) {
      if ((result = page.delete()) == Bool.False) {
        if ((result = page.delete()) == Bool.False) {
          return Bool.FileNotFound;
        }
      }
    }
    else if (result == Bool.FileNotFound) return Bool.False;
    
    return Bool.True;
  }
}

John YaYa · 2006-03-28 Reply Admin

loneprogrammer:
No, that's a bug in IE. Every other web browser does not do this. IE should be fixed to respect the HTML standard.

In a day where I've been on the receiving end of a pair of WTF Hat Tricks, this is officially the funniest thing I've heard all day ... :P

Thank you. Maybe I won't have to kill myself tonight. :)

(fingers crossed that my formatting doesn't get eaten)

loneprogrammer · 2006-03-28 Reply Admin

kipthegreat:

Come on, having a "view text only" button at the bottom of a page would look retarded. But having a "?textonly=1" link violates standard. But an onclick:submit() link works nicely for anyone not trapped in 1998.

And CSS works nicely for anybody not trapped in 2001.

Try to understand this -- HTML tags do NOT control what things look like. CSS controls what things look like.

E.g. the "ul" tag does NOT mean "make a bulleted list." It just makes a list. The CSS attribute "list-style-type: disc" is what makes it have bullets. If you have a "ul" tag with "list-style-type: upper-roman" then it gets Roman numerals instead of bullets, and if you say "list-style-type: none" then you have a list with no bullets at all!

2006-03-28 Reply Admin

I don't know where to start with this. It's just so wrong...

Then someone did the onClick wrong?

And how is that?

I think the old "hyperlinked documents" model is failing to keep up with the fact people are writing more and more complex systems, and by all means, use links forms, or whatever. Last time I checked, when you show an HTML layer over (for dynamic menus etc) form elements or any embedded element gets painted overtop of the HTML, even though it is on a layer behind it. Thats a pretty good reason to use links instead of fat widgets I'd say.

Hello 1998, this is 2006 calling. There's only one browser that does that, and only with the SELECT element: IE.

And, as I demonstrated in an earlier comment, you can make a button look like a regular link. It's not hard. The old "hyperlinked documents" paradigm works just fine, even today.

Also, GET requests are good for "modifier" requests at times, do you want a form button just to change a default language or some indescript setting?

Use POST.

To update a hit counter?

GET is fine for this. It's a side-effect, but only incidental and doesn't impinge on GET's idempotency.

I think its a problem when a programmer has a programming stylistic reason for limiting the freedom of the designers.

No the problem arises when the programmer is too lazy to do their job right, or when the designer is too lazy to use CSS to style their buttons.

Give them some guidelines, and hard rules where they really are needed, but seriously if a designer can come up with a richer and more appealing interface that use links to submit form posts, there is no reason in the world they should be forced to dumb-down their design.

Give me one instance where you think you're right, and I'll show you you're wrong.

K.

2006-03-28 Reply Admin

I am extremely embarrassed that this exact thing happened to me.

It's a little different, because the secret links were in javascript comments, and the search engine was a Chinese spam crawler. Also, all I lost was a few days of postings on my rant log and some really excellent poetry I wrote in college, and not all of the content of a government website.

John YaYa · 2006-03-28 Reply Admin

Dammit. Maybe someday I'll figure out how to make the stupid emoticons work correctly...

[image]

Then again, maybe not.

2006-03-28 Reply Admin

kipthegreat:
gwenhwyfaer:
bullseye:
...

PLEASE don't do this! The number of times I've clicked on what should have been a button on some page http://some.url/page and found myself directed to http://some.url/page/# because onClick events were silently discarded... If it needs to submit a form, make it a submit button. If it needs to execute JavaScript locally, make it an ordinary button. If it's a link, it should take me somewhere AND NOTHING ELSE.

Come on, having a "view text only" button at the bottom of a page would look retarded. But having a "?textonly=1" link violates standard. But an onclick:submit() link works nicely for anyone not trapped in 1998.

Then style the button differently. It works fine for anybody not trapped in 1999.

K.

2006-03-28 Reply Admin

marvin_rabbit:
Anonymous:
Total agreement. And it's not just "destructive" actions, but *any* action which causes a stateful change to the data is supposed to be performed by POSTs. That's sorta the whole point of having two separate types of requests in the first place.

Not quite anything. For instance, every time your webserver writes to its log file, you're causing a state change. However, such changes are ok because they don't interfere with GET's idempotency: you can do it time after time, and it's the same as doing it once: the extra data doesn't interfere with the running of the app.

What these idiots were doing, now that is another matter entirely.

Personally, I'm surprised nobody's brought up the "but form buttons are so ugly" chestnut. I've a way to smack that one down too.

Ahem:
<chestnut>
"But form buttons are so ugly."
</chestnut>

(Just curious.)

Style it with CSS. The 'use stable view' link on this page is actually a form button: http://talideon.com/wiki/?page=WikiEtiquette.

2006-03-28 Reply Admin

John YaYa:
loneprogrammer:
No, that's a bug in IE. Every other web browser does not do this. IE should be fixed to respect the HTML standard.

In a day where I've been on the receiving end of a pair of WTF Hat Tricks, this is officially the funniest thing I've heard all day ... :P

Thank you. Maybe I won't have to kill myself tonight. :)

(fingers crossed that my formatting doesn't get eaten)

I don't know why you find it so funny. It's not entirely false.

Most form controls in IE6 and below are rendered natively by IE itself except for one: SELECT. For that it uses Windows' one drop-down control, which means that it appears to render above anything else on the page. MS themselves regarded this as a bug and fixed it in IE7.

I think loneprogrammer deserves an apology, and Alex needs to fix that damned captcha.

bullseye · 2006-03-28 Reply Admin

kipthegreat:
PLEASE don't do this! The number of times I've clicked on what should have been a button on some page http://some.url/page and found myself directed to http://some.url/page/# because onClick events were silently discarded... If it needs to submit a form, make it a submit button. If it needs to execute JavaScript locally, make it an ordinary button. If it's a link, it should take me somewhere AND NOTHING ELSE.

I don't disagree. However, there are going to be situations (extensive DHTML for instance) where not using link events is extremely undesirable. Specifically if the "link" is located outside of a form.

Hubert Farnsworth:
You know what? I've got noscript installed in Firefox.

You are the web-developer's nemesis. [;)]

Maurits · 2006-03-28 Reply Admin

kipthegreat:
having a "?textonly=1" link violates standard.

No it doesn't.

2006-03-28 Reply Admin

We'd better patent the idea!

stevekj · 2006-03-28 Reply Admin

John YaYa:
Dammit. Maybe someday I'll figure out how to make the stupid emoticons work correctly...
[image]
Then again, maybe not.

OK, so how exactly did you do that? I'm pretty sure dragging them in doesn't work: A

I can copy and paste yours... [image]

But not so with the palette: pi

WTF?

NickPresta · 2006-03-28 Reply Admin

I've been lurking at this site for a while and I never really registered. After reading this, I had to say, anytime you rely on things that can be turned off/not present on all browsers or systems/or spoofed, you set yourself up for some damage.

I hope the dev. team that made the CMS doesn't get to touch anything again.

2006-03-28 Reply Admin

That's what that guy in Oklahoma would say, as he was dialing up the FBI to complain... :)

jamesCarr · 2006-03-28 Reply Admin

paddy:
gwenhwyfaer:
bullseye:
...

PLEASE don't do this! The number of times I've clicked on what should have been a button on some page http://some.url/page and found myself directed to http://some.url/page/# because onClick events were silently discarded... If it needs to submit a form, make it a submit button. If it needs to execute JavaScript locally, make it an ordinary button. If it's a link, it should take me somewhere AND NOTHING ELSE.

Then someone did the onClick wrong?

I think the old "hyperlinked documents" model is failing to keep up with the fact people are writing more and more complex systems, and by all means, use links forms, or whatever. Last time I checked, when you show an HTML layer over (for dynamic menus etc) form elements or any embedded element gets painted overtop of the HTML, even though it is on a layer behind it. Thats a pretty good reason to use links instead of fat widgets I'd say.
Also, GET requests are good for "modifier" requests at times, do you want a form button just to change a default language or some indescript setting? To update a hit counter?

I think its a problem when a programmer has a programming stylistic reason for limiting the freedom of the designers.
Give them some guidelines, and hard rules where they really are needed, but seriously if a designer can come up with a richer and more appealing interface that use links to submit form posts, there is no reason in the world they should be forced to dumb-down their design.

No, you're just someone too dumb to understand html. Otherwise you wouldn't refer to them in dreamweaver speak you dumbshit.

Naturally, "the old hyperlined document model" you refer to, of which I am assuming you mean those things called web standards, works just fine for those who actually now what they are doing, rather than dragging and dropping imaginary "widgets" and "layers" in frontpage.

d4ddyo · 2006-03-28 Reply Admin

Anonymous:
marvin_rabbit:
Anonymous:
Total agreement. And it's not just "destructive" actions, but *any* action which causes a stateful change to the data is supposed to be performed by POSTs. That's sorta the whole point of having two separate types of requests in the first place.

Not quite anything. For instance, every time your webserver writes to its log file, you're causing a state change. However, such changes are ok because they don't interfere with GET's idempotency: you can do it time after time, and it's the same as doing it once: the extra data doesn't interfere with the running of the app.

What these idiots were doing, now that is another matter entirely.

Personally, I'm surprised nobody's brought up the "but form buttons are so ugly" chestnut. I've a way to smack that one down too.

Ahem:
<chestnut>
"But form buttons are so ugly."
</chestnut>

(Just curious.)

Style it with CSS. The 'use stable view' link on this page is actually a form button: http://talideon.com/wiki/?page=WikiEtiquette.

And, in IE, it still looks like a button. Opera (8.5) shows it as having a background color. Point is, CSS is *not* the elixer for everything (unfortunately), and to ignore IE in terms of marketing is a mistake. Now, you *could* argue about the merits (or lack) of over-stylizing HTML pages in the first place....

jamesCarr · 2006-03-28 Reply Admin

kipthegreat:
gwenhwyfaer:
bullseye:
...

PLEASE don't do this! The number of times I've clicked on what should have been a button on some page http://some.url/page and found myself directed to http://some.url/page/# because onClick events were silently discarded... If it needs to submit a form, make it a submit button. If it needs to execute JavaScript locally, make it an ordinary button. If it's a link, it should take me somewhere AND NOTHING ELSE.

Come on, having a "view text only" button at the bottom of a page would look retarded. But having a "?textonly=1" link violates standard. But an onclick:submit() link works nicely for anyone not trapped in 1998.

Maybe you could use a small and simple dash of css to make that form button look like a link, not too difficult.

The real wtf isn't the forum, it's the forum users! :p

jamesCarr · 2006-03-28 Reply Admin

Anonymous:

And, in IE, it still looks like a button. Opera (8.5) shows it as having a background color. Point is, CSS is *not* the elixer for everything (unfortunately), and to ignore IE in terms of marketing is a mistake. Now, you *could* argue about the merits (or lack) of over-stylizing HTML pages in the first place....

<input value="No it doesn't" name="myButt" style="border: medium none ; background: transparent none repeat scroll 0%; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial; color: blue; text-decoration: underline;" type="button">

Uh oh.. someone set up the bitchslap! :p

jamesCarr · 2006-03-28 Reply Admin

Damn forum software ate the last one, and I cannot edit. :(

makomk · 2006-03-28 Reply Admin

your mom:
loneprogrammer:

It does not simulate the user clicking "everything." Only on the links, but not the buttons that submit forms.

what about links such as this? <a href="javascript:myform.Submit()">

Which the forum software mangles (hint: it doesn't fully grasp HTML - or, indeed, sanity.

kipthegreat:

Speaking of which, is anyone else annoyed that when a post in this forum gets 50 replies, the site uses POST rather than GET to go to replies 50-99? So whenever I'm on page 2 and hit refresh I get prompted as to whether I want to resubmit form data.

You're not - see my sig. It is possible to get to page 2 or more with GET requests; just insert a 2/ (or whatever page number you want) in the path before the post/thread number - e.g. http://thedailywtf.com/forums/2/65974/ShowPost.aspx is the second page of this thread. (There's another method using query strings too, IIRC). Unfortunately, the pager doesn't use this for some reason - pester Alex if you want it fixed...

2006-03-28 Reply Admin

paddy:

[B]ut seriously if a designer can come up with a richer and more appealing interface that use links to submit form posts, there is no reason in the world they should be forced to dumb-down their design.

You can debate whether an action is state-changing and form reducto ad absurdum cases all day long, but it doesn't diminish the fact that the web is design in a particular way, and designers shouldn't just be concerned with aesthetics. GET and POST exist for a reason, and designing for the web as if that factt didn't exist is like designing a car that only has a gas pedal.

You can have quite sophisticated designs without breaking the web. There are many examples if you care to open your eyes and look.

makomk · 2006-03-28 Reply Admin

stevekj:
John YaYa:
Dammit. Maybe someday I'll figure out how to make the stupid emoticons work correctly...
[image]
Then again, maybe not.

OK, so how exactly did you do that? I'm pretty sure dragging them in doesn't work: A

I can copy and paste yours... [image]

But not so with the palette: pi

WTF?

Heh - source for the "emoticon" is <a href="">pi</a> - that's truly a WTF

gwenhwyfaer:
bullseye:
...

PLEASE don't do this! The number of times I've clicked on what should have been a button on some page http://some.url/page and found myself directed to http://some.url/page/# because onClick events were silently discarded... If it needs to submit a form, make it a submit button. If it needs to execute JavaScript locally, make it an ordinary button. If it's a link, it should take me somewhere AND NOTHING ELSE.

If you must use a link, having the actual link go to a webpage containing a form (using POST) containing a single submit button and prompting the user to click to confirm, then using JavaScript on the link to submit a form directly and cancel the link navigation, would seem like a good solution to this problem...

dpm · 2006-03-28 Reply Admin

Otto:
GWA caused problems,

You misspelled "revealed". HTH.

2006-03-28 Reply Admin

Moral of the story is implement some sort of working authentication not amateur web hacks. This should never never never happen. Ever.

2006-03-28 Reply Admin

d4ddyo:
Anonymous:
marvin_rabbit:
Anonymous:
Total agreement. And it's not just "destructive" actions, but *any* action which causes a stateful change to the data is supposed to be performed by POSTs. That's sorta the whole point of having two separate types of requests in the first place.

Not quite anything. For instance, every time your webserver writes to its log file, you're causing a state change. However, such changes are ok because they don't interfere with GET's idempotency: you can do it time after time, and it's the same as doing it once: the extra data doesn't interfere with the running of the app.

What these idiots were doing, now that is another matter entirely.

Personally, I'm surprised nobody's brought up the "but form buttons are so ugly" chestnut. I've a way to smack that one down too.

Ahem:
<chestnut>
"But form buttons are so ugly."
</chestnut>

(Just curious.)

Style it with CSS. The 'use stable view' link on this page is actually a form button: http://talideon.com/wiki/?page=WikiEtiquette.

And, in IE, it still looks like a button. Opera (8.5) shows it as having a background color. Point is, CSS is *not* the elixer for everything (unfortunately), and to ignore IE in terms of marketing is a mistake. Now, you *could* argue about the merits (or lack) of over-stylizing HTML pages in the first place....

I forgot IE doesn't support inherit, so sue me :-) It's fixed now, so check again. See what I mean now?

I'm not saying it's an elixer, just that it's not used as well as it ought to be.

K.

2006-03-28 Reply Admin

And a big thanks to the guys at 24.211.9.119 and 62.16.239.96 who thought it'd be terribly clever to delete some of the content on my wiki. Obviously you've never heard of a version control system before. That really shows how mature you guys are.

2006-03-28 Reply Admin

makomk:
your mom:
loneprogrammer:

It does not simulate the user clicking "everything." Only on the links, but not the buttons that submit forms.

what about links such as this?
Which the forum software mangles (hint: it doesn't fully grasp HTML - or, indeed, sanity.
kipthegreat:

Speaking of which, is anyone else annoyed that when a post in this forum gets 50 replies, the site uses POST rather than GET to go to replies 50-99? So whenever I'm on page 2 and hit refresh I get prompted as to whether I want to resubmit form data.
You're not - see my sig. It is possible to get to page 2 or more with GET requests; just insert a 2/ (or whatever page number you want) in the path before the post/thread number - e.g. http://thedailywtf.com/forums/2/65974/ShowPost.aspx is the second page of this thread. (There's another method using query strings too, IIRC). Unfortunately, the pager doesn't use this for some reason - pester Alex if you want it fixed...

First post here, let's see if it survives the forum software.

The thing with the GET/POST is that the first page you are entering the page from another URL so you get plain GET, when you change the pages using the links you trigger a "PostBack" (ASP.NET-ese) for a POST, so from there forward all you're going to get are POSTS.

Nice isn't (</SARCASM>)

P.D.: Not native speaker of English, hope is clear enough

---------------------

A little more WTF from the forum software (http://www.thedailywtf.com/forums/AddPost.aspx?PostID=66086&Quote=True)

The Spider of Doom

Leave a comment on “The Spider of Doom”