W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2010

[whatwg] element "img" with HTTP POST method

From: Nils Dagsson Moskopp <nils-dagsson-moskopp@dieweltistgarnichtso.net>
Date: Fri, 10 Dec 2010 17:31:38 +0100
Message-ID: <20101210173138.50990117@desudesudesu>
Martin Janecke <whatwg.org at kaor.in> schrieb am Thu, 9 Dec 2010 19:59:02
+0100:

> 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),

I do not agree. Maybe I do not grasp something here, but I was of
the impression that POST creates content while GET requests resources,
also explicitly resources that are created by ?data-producing
process[es]?.

Also, quote RFC 2616, Section 9, Subsection 5:

> the posted entity is subordinate to that URI in the same way that a
> file is subordinate to a directory containing it, a news article is
> subordinate to a newsgroup to which it is posted, or a record is
> subordinate to a database. 

I don't see this with image generation at all.

Back to your mail:

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

These are implementation issues. What makes you believe that the
relatively complex task of adding a new attribute would be implemented
before the relatively simple task of extending the URL length?

Also, filtering out GET variables from logs is a simple task.

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

New clients. What would old clients do?
What if the given URL contained GET variables?

> [?]
>
> === Example/Use Cases ===
> 
> (1) MimeTeX and MathTeX are used to display mathematical formulae in
> web pages. This is often used in science forums. Info:
> 
> [?]

Why not use inline MathML? It is semantically accurate and stylable.

> [?]
>
> <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">

This seems to be largely an aesthetical (but non-backwards-compatible!)
change. Also, at least to me it does not seem to be ?more? readable.


Cheers,
-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101210/295eaf50/attachment.pgp>
Received on Friday, 10 December 2010 08:31:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:02 UTC