- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 28 Apr 2011 21:28:47 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 28 April 2011 14:28:47 UTC