I like the general idea (this would also get rid of the problem that, right now, it's unnecessarily hard for authors to show idempotent and non-idempotent actions in a unified visual style), though this would also present serious security vulnerabilities, especially in forum pages.
There are quite a number of older web forums that sanitize their HTML using black lists and would not strip new attributes like "post-data". For malicious users, it would be very easy to include e.g. <img src="./do_post.php" post-data="thread_id=42&post_content=Go visit (some spam URL)"> in their signature and have users doing involuntary posts by simply viewing a thread. A possible remedy could be to have the page author "opt in" to that feature, e.g. with a special meta tag. If the meta tag is not present, the post-data attribute would be ignored. Another problem is what to do with context menu entries like "copy link location"/"copy image location" etc. Maybe links/images with post-data could be treated like <input> elements regarding their context menu. Regards, Philipp Serafin On 09.12.2010 20:04, Ashley Sheridan wrote: > On Thu, 2010-12-09 at 11:01 -0800, Adam Barth wrote: >> We've seen use cases for a similar feature for iframes and hyperlinks. >> For example: >> >> <a href="/logout" post-data>Logout</a> >> >> would be more semantically correct that just <a >> href="/logout">Logout</a> because it would generate a POST instead of >> a GET. >> >> Adam >> >> >> On Thu, Dec 9, 2010 at 10:59 AM, Martin Janecke <[email protected] >> <mailto:[email protected]>> wrote: >> > Hi all, >> > >> > What is your opinion on enabling the HTTP POST method for the img element? >> > The motivation behind this is that there are services which generate >> > images automatically based on parameters given -- nowadays provided as >> > query string in a GET request -- for inclusion in web pages. I've listed >> > examples below. However, these query strings can get really long and it >> > seems to me that the HTTP POST method would be more appropriate than the >> > GET method for such services. Not only because it would better match the >> > intended use of these methods (see >> > http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9), but also for >> > practical reasons: URLs in GET requests are (inconsistently) limited in >> > length by browsers and server software, which limits these services >> > (inconsistently). And long URLs bloat server logs. >> > >> > This could be implemented with an optional attribute, e.g. "post-data". >> > The client would request the source using the POST method if the attribute >> > is present and send the attribute's value as the request's message body. >> > >> > Martin >> > >> > PS: This doesn't necessarily need to be restricted to img elements. If you >> > encountered use cases for other elements that embed content, feel free to >> > add them. >> > >> > >> > === Example/Use Cases === >> > >> > (1) MimeTeX and MathTeX are used to display mathematical formulae in web >> > pages. This is often used in science forums. Info: >> > >> > http://www.forkosh.com/mathtex.html >> > http://www.forkosh.com/mimetex.html >> > >> > Current use in web pages: >> > >> > <img >> > src="http://www.forkosh.dreamhost.com/mathtex.cgi?\begin{align}%0D%0A\Gamma(z)%20%26%3D%20\lim_{n\to\infty}\frac{n!\;n^z}{z\;(z%2B1)\cdots(z%2Bn)}%20%3D%20\frac{1}{z}\prod_{n%3D1}^\infty\frac{\left(1%2B\frac{1}{n}\right)^z}{1%2B\frac{z}{n}}%20\\%0D%0A\Gamma(z)%20%26%3D%20\frac{e^{-\gamma%20z}}{z}\prod_{n%3D1}^\infty\left(1%2B\frac{z}{n}\right)^{-1}e^{z/n}%0D%0A\end{align >> > >> > <http://www.forkosh.dreamhost.com/mathtex.cgi?%5Cbegin%7Balign%7D%0D%0A%5CGamma%28z%29%20%26%3D%20%5Clim_%7Bn%5Cto%5Cinfty%7D%5Cfrac%7Bn%21%5C;n%5Ez%7D%7Bz%5C;%28z%2B1%29%5Ccdots%28z%2Bn%29%7D%20%3D%20%5Cfrac%7B1%7D%7Bz%7D%5Cprod_%7Bn%3D1%7D%5E%5Cinfty%5Cfrac%7B%5Cleft%281%2B%5Cfrac%7B1%7D%7Bn%7D%5Cright%29%5Ez%7D%7B1%2B%5Cfrac%7Bz%7D%7Bn%7D%7D%20%5C%5C%0D%0A%5CGamma%28z%29%20%26%3D%20%5Cfrac%7Be%5E%7B-%5Cgamma%20z%7D%7D%7Bz%7D%5Cprod_%7Bn%3D1%7D%5E%5Cinfty%5Cleft%281%2B%5Cfrac%7Bz%7D%7Bn%7D%5Cright%29%5E%7B-1%7De%5E%7Bz/n%7D%0D%0A%5Cend%7Balign>}" >> > alt="gamma function definition"> >> > >> > Possible future use: >> > >> > <img src="http://www.forkosh.dreamhost.com/mathtex.cgi"; >> > post-data="\begin{align}%0D%0A\Gamma(z)%20%26%3D%20\lim_{n\to\infty}\frac{n!\;n^z}{z\;(z%2B1)\cdots(z%2Bn)}%20%3D%20\frac{1}{z}\prod_{n%3D1}^\infty\frac{\left(1%2B\frac{1}{n}\right)^z}{1%2B\frac{z}{n}}%20\\%0D%0A\Gamma(z)%20%26%3D%20\frac{e^{-\gamma%20z}}{z}\prod_{n%3D1}^\infty\left(1%2B\frac{z}{n}\right)^{-1}e^{z/n}%0D%0A\end{align}" >> > alt="gamma function definition"> >> > >> > >> > (2) QR-Code generators encode texts or URLs in a way that can be easily >> > read by devices such as cell phones with built-in cameras. Info and >> > generator: >> > >> > http://qrcode.kaywa.com/ >> > >> > Current use in web pages: >> > >> > <img >> > src="http://qrcode.kaywa.com/img.php?s=8&d=Ah%2C%20distinctly%20I%20remember%20it%20was%20in%20the%20bleak%20December%2C%0D%0AAnd%20each%20separate%20dying%20ember%20wrought%20its%20ghost%20upon%20the%20floor >> > >> > <http://qrcode.kaywa.com/img.php?s=8&d=Ah%2C%20distinctly%20I%20remember%20it%20was%20in%20the%20bleak%20December%2C%0D%0AAnd%20each%20separate%20dying%20ember%20wrought%20its%20ghost%20upon%20the%20floor>." >> > alt="qrcode"> >> > >> > Possible future use: >> > >> > <img src="http://qrcode.kaywa.com/img.php"; >> > post-data="s=8&d=Ah%2C%20distinctly%20I%20remember%20it%20was%20in%20the%20bleak%20December%2C%0D%0AAnd%20each%20separate%20dying%20ember%20wrought%20its%20ghost%20upon%20the%20floor." >> > alt="qrcode"> >> > >> > > > > It makes sense in the case of a link like that, as it is changing some > state on the server, which is what POST data was intended to do. If > images are called with POST data, then that would prevent them being > cached, which can be done with GET as GET isn't meant to change any > state on the server, meaning potentially a lot more traffic to save > some log files from getting a bit big. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > >
