[whatwg] element "img" with HTTP POST method

[Ian Hickson]

On Thu, 9 Dec 2010, Martin Janecke wrote:
> 
> What is your opinion on enabling the HTTP POST method for the img 
> element?

This would unfortunately be somewhat impractical, due to the 
idempotency-assuming nature of <img>: it's generally assumed to be safe 
for images to be fetched an arbitrary number of times with no bad 
side-effects.


> 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.

The length of the data is not a relevant concern when picking GET vs POST. 
GET and POST have different semantics:

> Not only because it would better match the intended use of these methods 
> (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9)

It doesn't seem that it would. What situations did you have in mind where 
a POST would be more semantically suitable?


> 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.

Nothing precludes an author from uploading the data first (using POST), 
getting back a unique ID, and then using that ID with a GET for an image, 
which would seem to resolve this.

In the meantime, one can do a POST for an image using XHR2 and the File 
API; or by scripting a form that posts a request to an <iframe> or 
<object> to render the resulting image. If we see a lot of that kind of 
thing then it would be evidence that we should revisit this.


> === 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}" 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">

This seems very wrong. That's totally a GET semantic, not a POST semantic.


> (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." 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">

Again, this seems like a GET, not a POST.


On Thu, 9 Dec 2010, 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.

This is possible today:

   <form action=/logout method=post>
    <button type=submit>Logout</button>
   </form>

Using an <a> for this would be inappropriate UI. (Hyperlinks should be 
idempotent.)


On Thu, 9 Dec 2010, Philipp Serafin wrote:
>
> 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.

IMHO, it's too _easy_ for authors to show idempotent and non-idempotent 
actions in a unified style! Why would we want this to be more common?


On Thu, 9 Dec 2010, Tab Atkins Jr. wrote:
>
> I don't believe there are any declarative ways to trigger involuntary 
> POSTs, are there?

test.html on this page has no script:

   http://damowmow.com/playground/demos/http/002/


On Fri, 10 Dec 2010, Benjamin Hawkes-Lewis wrote:
> 
> The most popular browser currently limits URLs to 2,083 characters.
> 
> http://support.microsoft.com/kb/208427
> 
> Your given examples fit comfortably within these limits; do you have a 
> real-world example of an image URL that falls foul of this constraint?
> 
> Apparently, Firefox/Safari/Opera already support much longer URLs:
> 
> http://blogs.nitobi.com/alexei/?p=163
>
> I think at some point repeatedly GETing or POSTing large amounts of data 
> to display an image becomes unrealistically wasteful of bandwidth, 
> compared to generating the image once and reusing the created image URL.

Indeed.


On Fri, 10 Dec 2010, Martin Janecke wrote:
> 
> That's a good idea. Can we define a minimum length in the spec that 
> should/must be supported? As a point of reference for browser vendors 
> and web page authors? I didn't find a reliable point of reference other 
> than http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1 ...

There's theoretically no limit; currently the limit is a matter of 
practical hardware or platform limitations.


On Fri, 10 Dec 2010, Julian Reschke wrote:
> 
> We can't change what RFC 2616 says, but we *did* already change this in 
> the drafts for the next revision:
> 
> "Various ad-hoc limitations on request-target length are found in 
> practice. It is RECOMMENDED that all HTTP senders and recipients support 
> request-target lengths of 8000 or more octets." 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-12.html#rfc.section.4.1.2.p.19>

This hopefully should handle the cases mentioned above.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'