News for hackers. Stuff that matters.
Re:Finally, voting without refresh by palish on Tuesday June 12, 2007 @04:57PM (#27601)
Er.. So that means it's a GET request, and GET requests which modify state on a website are bad. Things like Google Web Accelerator silently visit all the links on the page and cache the result in case you decide to visit that link. So there might be some problems for people using those (For example, their accelerator might accidentally upvote all the comments in every comment page they visit)
Re:Finally, voting without refresh by palish on Tuesday June 12, 2007 @05:05PM (#27603)
Yep, I just confirmed this by viewing the source code, then visiting http://news.ycombinator.com/a?fnid=oO6e74w9Mq manually. It upvoted the "bandsintown" article. A misbehaved web accelerator could upvote every single article on the front page, and every comment in each comment page that they visit.

Re:Finally, voting without refresh by palish on Tuesday June 12, 2007 @05:10PM (#27604)
Okay, so I just downloaded Google Web Accelerator and it doesn't upvote the links.. It must be smart enough not to. I'm worried about other ones that people may be using though. (Doesn't fasterfox do some kind of prefetching?)
Re:Finally, voting without refresh by paul on Tuesday June 12, 2007 @05:58PM (#27622)
It's just an adaptation of the old, non-js html, in which the arrows were just links, and it's written such that it will work in the old way if the js doesn't work for some reason (like I never bothered to test it with all the browsers).

Anything that assumes that GET links can be arbitrarily followed will break stuff all over the web. GWA needs all kinds of heuristics to avoid that kind of thing. (maybe they avoid sending cookies or session ids?)

Re:Finally, voting without refresh by Bogtha on Wednesday June 13, 2007 @02:27PM (#27844)
> Anything that assumes that GET links can be arbitrarily followed will break stuff all over the web.

Arbitrarily performing GETs is something condoned by the HTTP 1.1 specification. Anything that assumes that GETs won't be arbitrarily followed is clueless.

You'd think people would have learned this the first time around. Don't write out-of-spec code and then complain when conforming code comes along and trashes your app. It's your bug, not theirs.

> GWA needs all kinds of heuristics to avoid that kind of thing.

How reliable. Wouldn't it be better to follow the spec so this kind of guesswork wasn't necessary?

Re:Finally, voting without refresh by palish on Tuesday June 12, 2007 @06:01PM (#27625)
Except it's vulnerable to an iframe exploit. See: http://news.ycombinator.com/item?id=27615
Re:Finally, voting without refresh by paul on Tuesday June 12, 2007 @06:12PM (#27632)
False (that GET causes the problem), see http://news.ycombinator.com/item?id=27629
Re:Finally, voting without refresh by benhoyt on Tuesday June 12, 2007 @08:47PM (#27658)
Google Web Accelerator won't follow the link, because it's got query parameters (a ? in the URL). See their help: http://webaccelerator.google.com/webmasterhelp.html#prefetch3

It's just as well, too -- GETs are used so often for this kind of stuff that any web acceleration tool which ignored this would break lots of sites.

Re:Finally, voting without refresh by ralph on Wednesday June 13, 2007 @06:17AM (#27753)
GWA did use to follow all GETs, including those with parameters, and did cause all kinds of grief because of poorly written web sites, so they added the query parameter check to work around it.
Re:Finally, voting without refresh by npk on Tuesday June 12, 2007 @05:11PM (#27605)
palish, interesting. Something I've never thought about. Do web accelerators typically not follow POST requests?
Re:Finally, voting without refresh by palish on Tuesday June 12, 2007 @05:12PM (#27606)
They can't reliably, because POST requests usually get data from forms when you click 'submit'. The other way to initiate a POST is using xmlhttprequest, setting the method to 'POST', and then sending your data.