intertwingly

I think it will take more than an easy method of adding new buttons-within-POST-forms to ween people off dangerous links. For one thing, you can’t nest a form inside another form so there are large chunks of web applications where a button can’t be placed. I have an idea for a gracefully degrading Ajax solution, but it’ll have to wait for a week so I can get my dissertation out of the way...

I’d comment there,  but registration is required.

We’ve already got a ticket pending for a link_to_post which basically does the same thing as this proposal but uses javascript to actually render it as a link.

[link]

A proposal was made there to provide a ‘post-button’ helper as well/instead.

We could do with some feedback on these issues from some people well versed in the relevant RFCs.  I understand Phil’s reluctance to use links instead of buttons, but clearly some designers prefer them. 

The issue of nested-forms is still there though.

Michael, sorry about the need to register to comment on my site.  It helps control comment spam.

Simon, regarding the nested-forms problem, there are at least two semi-reasonable options for solving it. One option is to just use a regular submission button (without the tiny wrapper form) that passes local state when clicked. The other is to use a link to a confirmation page, where a form submission can occur.

I explained both in more depth in my response to your comment on my site:

[link]

Cheers,
Tom

Well, I think W3C and SAFE-GET crowd are living in a dreamland. Making sure HTTP GET links are “safe” makes websites legally unaccountable? Doing the right thing for whose benefit? And once enough websites convert to SAFE-GET and users start to assume everything that looks like a link is safe, whose going to protect them when they run into UNSAFE-GET sites? Who is going to stop them and with what?

In retrospect, it was rude of me to post a disparaging comment out of the blue. When I have something to say, I tend to be a brute. Sorry about that. From now on, I’ll post negative comments at my blog.

I’ve just written how the web app folk can easily keep using links with Javascript popup confirmations, so long as they’re diligent about doing it correctly. FWIW, Phil is 90% of the way there.

Don: in case you haven’t been following this discussion closely, Data has been lost.  This stuff matters.

Over the weekend, we have gone from blocking this one tool, to much more general solutions.

Good stuff.

Why is this only happening now with pre-fetching?  Why weren’t regular web crawlers causing this problem before?

Why weren’t regular web crawlers causing this problem before?

Because the pages (and links) in question are part of web applications that require login, either HTTP auth or cookie-based.  So the web crawlers were only crawling the “guest” part of the app (the login page, the welcome page, etc.)

GWA operates on the user’s machine, so once the user logs in, GWA has the same privileged access as the user.

Sam, while I can see why some might view unintended use of HTTP GET as the cause of the Google Web Accelerator problem, I think:

1. it is impossible to make all HTTP GETs safe
2. products like Google Web Accelerators must give way to wrong yet common practice.
3. Backpack users should sue Google for insufficiently warning them about harmful side effects.

IMHO, the only realistic solution is to introduce markup hints that accelerators can take advantage of. For example, a meta-tag that say all links are safe for prefetching. For individual links, rel attribute can be used (noprefetch). I realize that this path leads to clutter of bandaid solutions but I don’t see any realistic alternative.

The markup hints are <a href='… and <input type='submit' ….

What about online ads then? Online ad links are definitely not idempotent since each fetch translates to a chi-ching for somebody (i.e. Google). So should all online ad links be changed to use POST? To me, GWA is a problematic technology that should not have been let loose in the first place, not even as a beta.

Don: by that reasoning, all search engines should be banned (most ads are on the public web and don’t hide behind authentication schemes).  Also, I personally don’t believe that the legal system should be among the first recourses as that process will undoubtedly bring up the question as to what the relevant standards have to say on the matter.

1. it is impossible to make all HTTP GETs safe

To quote Monty Python, “Please state the logic underlying that conclusion.”  ("Well it’s so clean." "It’s certainly uncontaminated by cheese.")

2. products like Google Web Accelerators must give way to wrong yet common practice.

Probably true.  Google’s made a lot of money their ability to write million-dollar code in the face of significantly-less-than-million-dollar markup (source).  It doesn’t make any sense for them to start whining about lack of standards compliance now.  Not that they’re whining, mind you.  I haven’t heard a peep from them since this whole thing started.  The whining is mostly confined to web developers who make a lot of noise about the selective group of web standards they find convenient.

3. Backpack users should sue Google for insufficiently warning them about harmful side effects.

“Besides the run-of-the-mill morons, there are [those who] work from examples, and ship code, and get yelled at, just like all the other morons. But then when they finally bother to read the spec, they magically turn into assholes and argue that the spec is ambiguous, or misleading in some way, or ignoreable because nobody else implements it, or simply wrong. These people are called sociopaths.”  (source)

There has been a lot of fascinating discussion going on today about Google’s latest ‘beta’ product release: the Google Web Accelerator .... [more]

Trackback from the power of 0ne

Backpack links would be safer if they used querystrings instead of overloading path. Googel states that URLs with “?” in them are not pre-fetched.

Kids shouldn’t be playing in the streets yet they do despite what we tell them. When a car runs over a kid playing in the street, what should the parents do? Spank the kid and let the driver go because kids shouldn’t be playing in the street? IMHO,...

[link]...

I have another kludgy solution for the nested forms problem: keep track of whether you are already in a form or not and if so, place a closing form tag before you put in the form for your submit button.  Then restart the form afterwards, adding javascript in both form pieces to grab the data from the other form fragment and submit it along with this one.  Pretty ugly huh?  Anyway, it might be possible.