- From: Nils Dagsson Moskopp <nils-dagsson-moskopp@dieweltistgarnichtso.net>
- Date: Fri, 10 Dec 2010 17:31:38 +0100
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