[whatwg] element "img" with HTTP POST method

[Benjamin Hawkes-Lewis]

On Thu, Dec 9, 2010 at 6:59 PM, Martin Janecke <whatwg.org at kaor.in> wrote:
> 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),

POST is a sort of catch-all method, but what here do you think makes
POST a better match than GET?

"The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI. If the Request-URI refers to a
data-producing process, it is the produced data which shall be returned
as the entity in the response and not the source text of the process,
unless that text happens to be the output of the process."

This seems to perfectly fit retrieving a produced image.

A request specifying an image by parameters is:

   - "safe" (the end-user does not need to be aware of or accountable
     for effects other than retrieval, e.g. they're not making a payment
     or submitting a comment).
   - "idempotent" (the effects of the first request are the same as
     for subsequent requests - you get the same image).

GET should be safe and idempotent. POST need not be.

See also:

http://www.w3.org/2001/tag/doc/whenToUseGet.html

> but also
> for practical reasons: URLs in GET requests are (inconsistently)
> limited in length by browsers and server software, which limits these
> services (inconsistently).

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.

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

Increasing URL limits to (say) 10,000 characters by spec would have a
better backwards compatibility story than a "post-data" attribute, since
it would work in many of today's browsers.

> === Example/Use Cases ===
>
> (1) MimeTeX and MathTeX are used to display mathematical formulae in
> web pages.

Only future browsers could use "post-data" and are better off
implementing inline MathML to support this use-case:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#mathml

In any case, are many formulas more than 10,000 characters?

> (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:

QR codes have a maximum capacity of 7,089 characters, well within the
10,000 characters requirement I suggest above.

http://en.wikipedia.org/wiki/QR_Code

--
Benjamin Hawkes-Lewis