[whatwg] element "img" with HTTP POST method

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 <whatwg.org at kaor.in <mailto:whatwg.org at kaor.in>> 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101209/1d3fc653/attachment-0001.htm>

Received on Thursday, 9 December 2010 11:41:27 UTC